Skip to main content
Resources

Email from Bruce Tonkin to Tim Cole

Editorial note: Although Melbourne IT responded in less than two days to ICANN's original request for answers to its list of questions sent out on 18 January 2005, the registrar requested an opportunity to slightly modify its response before publicly posting it on the ICANN website. The date of this document reflects the subsequent modified response and should not in any way suggest that Melbourne IT was slow in responding to ICANN's original query. No substantive changes were made to the original response.

Date: Thursday, January 27, 2005
From: Bruce Tonkin
To: Tim Cole
Subject: Public response to ICANN questions on the panix.com issue

To: ICANN

To provide some context to the answers below, I will start will the following statements.

The hijack occurred because a reseller of Melbourne IT failed to follow the process for seeking authorisation for a domain name transfer request. Melbourne IT has agreements with some of its resellers, where the reseller agrees to undertake authentication of a transfer request using the ICANN authorisation procedure, as the reseller has a direct relationship with the registrant. In this case the reseller failed to follow the procedure. Melbourne IT has withdrawn the ability for that reseller to initiate a transfer without Melbourne IT directly authenticating the transfer.

Melbourne IT has an audit and compliance program around its reseller activities, including transfers. As a result of this incident Melbourne IT is carrying out an immediate audit of all its resellers that authenticate transfers, and will implement improvements to its regular audit process. It is important to note that this is the first incident of this nature that Melbourne IT is aware of in its 5 years of operation as a .com registrar, with hundreds of thousands of transfers being successfully completed.

> In order to assist with our efforts to both ensure compliance with the current policy, and to explore possible improvements to the current policy, we would appreciate it if you could please promptly review and reply to the following questions:

> 1. Under the Registrar Accreditation Agreement and the new ICANN transfer policy, registrars are obligated to establish that they have the express authorization of the registrant prior to initiating a transfer, and to keep copies of all transfer authorization records:

> a) Please provide ICANN with the copy of the Whois data for PANIX.COM > that Melbourne IT obtained prior to initiating the transfer.

Melbourne IT did not log a full copy of the WHOIS information from the losing registrar in this instance as this function was delegated to the reseller for this particular domain name.

Melbourne IT did collect from the .com registry (Verisign) and store the status of the NameServers at the time of the transfer:

NS1.ACCESS.NET
NS2.ACCESS.NET

The following information was captured outside of the process:

Public Access Networks Corp.
15 West 18th Street, 5th floor
New York, NY 10011
US

Registrar: DOTSTER
Domain Name: PANIX.COM
Created on: 22-APR-91
Expires on: 23-APR-05
Last Updated on: 15-JAN-05

Administrative, Technical Contact:
Hostmaster, Panix hostmaster@panix.com
Public Access Networks Corp.
15 West 18th Street, 5th floor
New York, NY 10011
US
212-741-4400
212-741-5311

Domain servers in listed order:
NS1.ACCESS.NET
NS2.ACCESS.NET

> b) Provide a copy of the authorization that Melbourne IT relied on to initiate the transfer.

In this case the reseller failed to seek authorisation from the registrant as displayed in the losing registrar's WHOIS, as required under our agreement with them. As a result there was no authorization.

> c) What form of identification Melbourne IT use to establish that it had the express authorization of the registrant prior to initiating the transfer?

See response above.

> 2. The RAA also requires registrars to maintain records of the submission date and time, and the content, of all registration data (including updates) submitted by registrars to the registry. Please provide ICANN with a copy of all registration data Melbourne IT submitted to the registry operator regarding PANIX.COM.

Below is a summary of events as logged in our system. Times are Australian Eastern Standard (AEST) time.

Transfer was initiated on the 08 Jan 2005 4:01:42 pm and completed on the 15th of January. 01:03:34 am

With the original Nameservers as shown at Losing registrar WHOIS and as landed in our Database 15-JAN-05 NS1.ACCESS.NET NS2.ACCESS.NET

Redelegated, by the Melbourne IT reseller on behalf of their customer, 15-JAN-05 04:56:39 pm ns1.ukdnsservers.co.uk ns2.ukdnsservers.co.uk

Changed back by Melbourne IT customer service, 17 January 09:30 am to NS1.ACCESS.NET NS2.ACCESS.NET

Below are the details of the registrant as provided to us by the reseller:

Organisation Contact
Licence Holder Name vanessa Miranda
Organisation Name
Address 1 1010 Grand Cerritos Ave
Address 2
City
State NV
Postcode 89123
Country USA
Email Address
Phone Number
Fax Number

Administrative Contact
Title
First Name na
Last Name vanessa Miranda
Institution
Position
Address1 1010 Grand Cerritos Ave
Address2
City Las Vegas
State NV
Postcode 89123
Email jzoh@yahoo.com
Phone +44.702413697
Fax +44.7026413697

> 3. The new transfer policy includes a transfer "undo" mechanism intended to reverse any transfers initiated by mistake or otherwise not in accordance with transfer policy.

The undo mechanism was not used. The normal transfer mechanism provided by Verisign was used.

At around 2:30pm (AEST), Melbourne IT requested that Dotster initiate a transfer from their end using the normal transfer command. Melbourne IT manually approved the request as soon as it was received around 6pm on Monday (AEST).

The CEO of Melbourne IT received a call from the the CEO of panix.com on Sunday. This was referred to the legal team which informed the CEO of panix.com that Melbourne IT staff would first need to investigate the authenticity of the claims made. Staff performed further checks to authenticate the request, and reverted the DNS information to its orginal state as stored in Melbourne IT's systems around 9:30am on Monday.

Melbourne IT also received calls from Verisign staff on Monday morning (AEST).

 

Regards,

Dr Bruce Tonkin
Chief Technology Officer
Melbourne IT Limited

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""icann.org"" is not an IDN."