Skip to main content

Email from Tim Cole to Bruce Tonkin

Dear Bruce:

We have completed our review of the unauthorized transfer of <>. ICANN considers this to have been one of the more serious breaches of its policies by an accredited registrar. We are also very concerned by Melbourne IT's explanation that the incident happened because Melbourne IT had purportedly “delegated” to a reseller the critical responsibility for obtaining the consent of the registrant prior to submitting a transfer request to the registry. While we appreciate Melbourne IT's report that it has withdrawn the offending reseller’s ability to independently initiate transfers, Melbourne IT has indicated that it intends to continue to operate under agreements with other resellers that provide that Melbourne IT will not directly and independently verify the intent of registrants prior to initiating transfer requests. While we review the appropriateness of these arrangements under current policies and agreements, we will ask the SSAC to review this reseller/delegation issue in the context of the investigation it has launched into the security and stability concerns raised by the <> hijacking.

Also, while there is no indication that recent changes to the Transfer Policy had any bearing on this incident (the same abuse could have occurred under either the old or new policy), this issue will be referred to the upcoming GNSO review of the transfer policy for the consideration of changes that could be implemented to reduce the risks made apparent by this incident.

Based on documentation provided by Melbourne IT, Ltd. and Dotster, Inc., the <> incident occurred as a result of a failure of Melbourne IT to obtain express authorization from the registrant in accordance with ICANN's Inter-Registrar Transfer Policy. The Transfer Policy is an ICANN Consensus Policy that went into effect on 12 November 2004. Both of the registrars were forthcoming with information about what took place concerning this transfer and the timeline below further details the events that took place. Correspondence detailing ICANN’s questions and the registrars’ responses can be found in the Correspondence section of the ICANN website including:

Email from Tim Cole to Bruce Tonkin 18 January 2005

Email from Tim Cole to Clint Page 18 January 2005

Email from Bruce Tonkin to Tim Cole 27 January 2005

Email from Ravi Puri to Tim Cole 27 January 2005


08 January 2005 (05:01 UTC) -Melbourne IT submitted a request to the registry to transfer the <> domain name. (Melbourne IT admits that this request was submitted without proper authorization. Since <> was not on “lock” status, the registry accepted the transfer request and initiated the transfer process within the registry system. Had the domain name been on registry or registrar lock status, the attempt by Melbourne IT to initiate a transfer would have been automatically rejected by the registry software.)

09 January 2005 (01:40 UTC) - Dotster received notification from the registry of the transfer request. (The registry notifies losing registrars of pending transfer requests in two ways: via email and registrar-specific reports available for download. Following the transmission of the transfer request to the losing registrar, there is a standard five day Transfer Pending Period. During the Transfer Pending Period losing registrars may take steps to verify the registrant's intent to transfer, including attempting to contact the registrant. The Policy also permits the losing registrar to request a copy of the authorization for the transfer from the gaining registrar. In this case, Dotster has indicated that it did not take any action in response to the notification of the transfer request and allowed the transfer to be approved automatically at the end of the five day Transfer Pending Period.)

14 January 2005 (14:03 UTC) - Transfer completed to Melbourne IT.

15 January 2005 (05:56 UTC) - Domain re-delegated by Melbourne IT's customer to new nameservers. (At this point it became evident to the legitimate registrant that the domain name had been hijacked. This was around 01:00 Saturday morning in the location of the registrant. The registrant spent several hours attempting to reach someone at each of the registrars and the registry who could take action to reverse the transfer.)

16 January 2005 (18:55 UTC) - ICANN sent emails to both registrars requesting an explanation and an immediate fix as appropriate. (ICANN’s inquiry to the registrars was prompted by a message to the public Registrars Constituency mailing list about the apparent hijacking.)

16 January 2005 (22:30 UTC) - Nameservers changed back by Melbourne IT Customer Service.

17 January 2005 (03:30 UTC) - Melbourne IT asked Dotster to initiate a transfer request in order to “undo” the transfer. (Registrars are encouraged to cooperate in this way to resolve disputes over transfers. The new Transfer Policy includes a formal dispute resolution process and a transfer undo mechanism, but it was not necessary to invoke either of those in this case.)

17 January 2005 (07:00 UTC) - Melbourne IT manually approved transfer requested by Dotster.

If you believe that further information would be helpful or corrections to the details above are warranted, please forward them to us and to SSAC for consideration in the review of this matter.



Tim Cole
Chief Registrar Liaison
Internet Corporation for Assigned Names and Numbers

cc: Kurt Pritz
John Jeffrey

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."