|
||
|
||
There’s a thread on NANOG to the effect that Panix, the oldest commercial Internet provider in New York, had its domain name ‘panix.com’ hijacked from Dotster over to MelbourneIT and it has pretty well taken panix.com and its customers offline.
Looks like this may be among the first high-profile unauthorized transfer under the new transfer policy.
It begs the question, despite the existence of the dispute policy under the new system, what provisions should there be for a situation like this where every hour causes untold damage to the party in question.
Maybe there needs to be some sort of emergency reversion where at least the name servers can be rolled back immediately while the contesting parties sort it out.
First off, I should go on the record as being in favour of the new Transfer Policy. I think it did a lot to alleviate the “lock-in” situation that many registrants were experiencing. I also think that the TDRP (Transfer Dispute Resolution Procedure, or whatever) is a good compliment to that policy.
What the panix.com case clearly demonstrates however, is a lack of an emergency rollback procedure in the face of a bad transfer.
Clearly, something went wrong in this case, despite panix.com’s belief that their registrar locks were set, somehow the domain was transferred. It matters little why or how it happened the point is there is no emergency rollback procedure in place when something like this happens and there needs to be.
An “Emergency TDRP” or ETDRP could be pretty simple:
A) Only available to domains who have transferred within the last N hours or X days.
B) Invoked by the losing Registrar or the losing Registrant directly who can supply bona-fides matching the previous version of the Whois record and can launch the process directly with the Registry.
C) Has effect of rolling name servers back and placing the domain under registry-lock status.
D) The regular TDRP (or something like it) then kicks in.
Sponsored byWhoisXML API
Sponsored byRadix
Sponsored byDNIB.com
Sponsored byCSC
Sponsored byVerisign
Sponsored byVerisign
Sponsored byIPv4.Global
A World-Renowned Source for Internet Developments. Serving Since 2002.
The Panix.com theft wasn’t even the biggest theft this weekend. Some adult sites (and mainstream too) were also hijacked, with traffic exceeding 500,000 unique visitors/day (i.e. Alexa top 2000 site, whereas Panix’s traffic is much smaller, probably 5000 to 10,000 visitors/day judging by their Alexa rank of 70,000).
With so much traffic being diverted, this could pose a real threat to internet infrastructure, if the diverted traffic was combined with a brand new (unpatched) browser exploit for example.
I’ve discussed this more fully on the GNSO GA mailing list, at:
http://gnso.icann.org/mailing-lists/archives/ga/msg02020.html
and the followups at:
http://gnso.icann.org/mailing-lists/archives/ga/
It looks like panix.com is back.
But, something obviously needs to be fixed. What I’d like to know is what went wrong in the first place. The rumor mill (e.g. Slashdot) says panix.com was in a locked state and that no notification steps took place. Dotster presumably still had panix.com in their database as if they were the owner. Did something go wrong at Dotster? At Panix? At MelbourneIT? At ICANN? All of the above?
I think it is important to know what did go wrong with this, and other, false/fraudulent/erroneous transfers. By knowing that, it is possible to better focus on the corrections that are needed.
As for the new transfer policy, I don’t think it really fixed anything. I do agree that the lock-in problem did exist; but it still exists (any registrar can just set all the locks).
But there are other problems, too.
A registrar should be reachable, by certain authorized parties (ICANN staff, and all other registrars, and possibly a designated independent domain ombudsman) 24 by 7. Registrar operations should be staffed 24 by 7 by people who either are authorized, or can contact an on-call person who is authorized, to investigate and take corrective measures when any problems happen.
Another possibility is that when a transfer to another registrar takes place, there be a freeze on any name server changes for 2-3 days (while notifications go out to all parties affected).
And I do like the rollback idea, but I also worry that it could be abused by rogue registrars.
There needs to be some better accountability of registrars. They need to be suspended (can’t add new domains or take incoming transfers) if they don’t follow the rules.
One point I want to mention: the current ICANN rules call for taking down a domain with invalid WHOIS information, presumely because the domain owner needs to be reachable. Perhaps in a similar vain, a minimum response time for registrars to be reachable by ICANN should be set.
Hello Mark,
I agree that an emergency rollback procedure would be useful.
With respect to the transfer policy. There is no evidence yet that the changes to the transfer policy resulted in this problem. The new policy has two protection mechanisms to prevent a transfer for a .com name. One is to place the name on transfer lock, and the second is for the losing registrar to send a confirmation message to the registrant. There is no evidence yet that either of this two mechanisms were in place.
Under the old policy registrars could deny a transfer under circumstances which were not clearly explained. This led to registrars denying almost all transfers. There is now certainty under the new policy. Provided the gaining registrar has authorisation from the registrnat, then the losing registrar cannot send a marketing message to the registrant and assume that no response to this message indicates that the transfer should not go ahead.
Regards,
Bruce Tonkin