panix.com recovery in progress

The latest shell host motd's:

. Hijack recovery underway (elr) Sun Jan 16 17:43:28 2005
.
. Recovery is underway from the panix.com domain hijack.
.
. The root name servers now have the correct information, as does the
. WHOIS registry. Portions of the Internet will still not be able to
. see panix.com until their name servers expire the false data. More
. info soon.
.
. panix.net status update (elr) Sun Jan 16 16:06:41 2005
.
. As some of our customers have noticed, there have been a few problems
. with using panix.net as a substitute for panix.com. We've fixed most
. of them:
.
. * if you change your return address to username@panix.net, it now works.
. Previously, it was getting re-written back to username@panix.com. Customers
. may need to do this to send mail to domains that use "Sender Address
. Verifcation" since the fake panix.com mail servers don't seem to be
. accepting mail right now.
.
. * The URL "http://www.panix.net/~USERNAME" automatically redirects to
. panix.com/~USERNAME. You can get around this by appending a / to the URL:
.
. http://www.panix.net/~USERNAME/
.
. * Addresses of the form xxxx@USERNAME.users.panix.net are working now.
.
. Of course, we're still working around the clock to solve the underlying
. problem with the hijacked domain.

Also 'dig +trace panix.com. ns':
  ; <<>> DiG 9.2.4rc6 <<>> +trace panix.com. ns
  ;; global options: printcmd
  . 489907 IN NS K.ROOT-SERVERS.NET.
  . 489907 IN NS L.ROOT-SERVERS.NET.
  . 489907 IN NS M.ROOT-SERVERS.NET.
  . 489907 IN NS A.ROOT-SERVERS.NET.
  . 489907 IN NS B.ROOT-SERVERS.NET.
  . 489907 IN NS C.ROOT-SERVERS.NET.
  . 489907 IN NS D.ROOT-SERVERS.NET.
  . 489907 IN NS E.ROOT-SERVERS.NET.
  . 489907 IN NS F.ROOT-SERVERS.NET.
  . 489907 IN NS G.ROOT-SERVERS.NET.
  . 489907 IN NS H.ROOT-SERVERS.NET.
  . 489907 IN NS I.ROOT-SERVERS.NET.
  . 489907 IN NS J.ROOT-SERVERS.NET.
  ;; Received 292 bytes from 216.234.161.25#53(216.234.161.25) in 3 ms
  
  com. 172800 IN NS a.gtld-servers.net.
  com. 172800 IN NS g.gtld-servers.net.
  com. 172800 IN NS h.gtld-servers.net.
  com. 172800 IN NS c.gtld-servers.net.
  com. 172800 IN NS i.gtld-servers.net.
  com. 172800 IN NS b.gtld-servers.net.
  com. 172800 IN NS d.gtld-servers.net.
  com. 172800 IN NS l.gtld-servers.net.
  com. 172800 IN NS f.gtld-servers.net.
  com. 172800 IN NS j.gtld-servers.net.
  com. 172800 IN NS k.gtld-servers.net.
  com. 172800 IN NS e.gtld-servers.net.
  com. 172800 IN NS m.gtld-servers.net.
  ;; Received 499 bytes from 193.0.14.129#53(K.ROOT-SERVERS.NET) in 143 ms
  
  panix.com. 172800 IN NS ns1.access.net.
  panix.com. 172800 IN NS ns2.access.net.
  ;; Received 105 bytes from 192.5.6.30#53(a.gtld-servers.net) in 57 ms

Yes, some folks with serious mojo got involved and things seem to be
on the way to "operationally fixed". AFAIK there is still no progress as
to the question of how this kind of transfer can happen without notice
to the transferred-from registrar (it's possible that there's progress
I don't know about).

I have just spoken to the tremendously tired and overworked ops staff at
Panix again. They would appreciate it very much if network operators
would reload their nameservers to help the good data for panix.com
propagate over the bad. Some Panix customer email now seems to be being
relayed to the actual Panix mail servers by the fake ones in the UK, which
is not such a good thing for obvious reasons.

Thor

It seems to be working for myself, however it appears as though SSH is
listening on port 80 on that machine.

<message>
SSH-1.99-OpenSSH_3.9p1 Protocol mismatch.
</message>

I can connect "correctly" via ssh on port 80.

Ken

There is more sertious problem here.

I can image 2 kinds of transfer:
- (1) domain is transferred WITHOUT CHANGES to the new registrar. Notice -
WITHOUT CHANGES. New registrar
should not change diomain without explicit order from owner.

- (2) Domain is expired and, after reasonable HOLD period, is transferred to
the new owner (and more likely new registrar). I can happen with the unused
domain only, or with domain which is expired.

In no case can 2 events happen together; if it happen, it is 100% indication
of hajacking. If someone want domain to be delegated to the new owner, he
91) change registrar if necessary, and (2) change donain owner.

All other approaches are very dangerous.