Lapse at Melbourne IT Enabled Hijacking

Domain registrar Melbourne IT today acknowledged that it failed to properly confirm a transfer request for, allowing the domain for the New York ISP to be hijacked for most of the weekend. The Panix incident has focused attention on recent ICANN rule changes that allow domains to be transferred more easily, which some registrars warned would also make it easier to hjack domains.

The hijacking disabled all email and Internet access for thousands of Panix customers, and persisted despite active efforts by the North American Network Operators Group (NANOG) to assist Panix in recovering the domain. The delays were blamed on unresponsiveness by several providers within the domain management system, but especially Melbourne IT, which appears to have no readily-accessible support on weekends. The hijacking was not reversed until Melbourne IT's offices opened in Australia Monday morning (late Sunday in New York).

"There was an error in the checking process prior to initiating the transfer, and thus the transfer should never have been initiated," Bruce Tonkin, the chief technology officer of Melbourne IT wrote in a message to the NANOG mailing list. "The loophole that led to this error has been closed." Tonkin did not describe the "loophole" but said the transfer of the domain from Dotster to Melbourne IT was initiated through an account at a Melbourne IT reseller, which was set up using stolen credit cards. "That reseller is analysing its logs and cooperating with law enforcement," he wrote.

Tonkin's explanation solves the mystery of how the hijacking occurred, but will bring greater scrutiny of new ICANN rules implemented in November, which allowed transfers to proceed with a customer confirmation by the "gaining" registrar but without a similar approval by the "losing" registrar. Networks Solutions and a number of other registrars locked down all customer domains as a precautionary step, warning that the changes could lead to hijackings. Domain locking prevents changes in the registrar, contact information and nameservers for a domain. Dotster did not automatically lock its domains, but Panix officials insisted that had been locked.

"No notification was received by either our registrar, Dotster, or us," says Ed Ravin, systems administrator at Panix, told CIO Today. "Whoever did this found a way to transfer domains without going through the normal process, and it's possible that anyone else's domain could be hijacked the same way."

Once Panix realized what had happened, it contacted .com registry operator VeriSign and tried to reach the registrars involved. "I spent *hours* trying to find working contact info for MIT and Dotster," Panix CEO Alex Rosen said. "I didn't find useful 24-hour NOC-type info anywhere. MIT apparently has no weekend support at all; I finally located their CEO's cellphone in an investor-relations web page."

Melbourne IT, which sells its domains through Yahoo and many other hosting firms, defended its claim of 24/7 customer service for resellers and technical contacts (although not retail customers), but said it will evaluate whether it can improve. "We are looking at our processes to ensure that incidents such as occurred with can be addressed more quickly within Melbourne IT, and also checking to ensure that an appropriate number of external people have access to the right contacts at Melbourne IT to fast track serious issues," Tonkin wrote.

Others called for a broader solution to fraudulent domain transfers. "What the case clearly demonstrates is a lack of an emergency rollback procedure in the face of a bad transfer," Mark Jeftovic wrote at CircleID, a portal for discussion of domain and DNS issues. "Clearly, something went wrong in this case. Despite'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."

Last week ICANN began seeking feedback on the November rule changes.