Given the recent panix.com hijacking, I will give an outline of the current ICANN transfers process for gtlds.

In the case of panix.com, evidence so far indicates that a third party that holds an account with a reseller of Melbourne IT, fraudulently initiated the transfer. The third party appears to have used stolen credit cards to establish this account and pay for the transfer. That reseller is analyzing its logs and cooperating with law enforcement. There was an error in the checking process prior to initiating the transfer, and thus the transfer should never have been initiated. The loophole that led to this error has been closed.

The transfer process has several checks and balances that are described below. It seems that in this case none of these worked. I can only comment on those from our end.

Note also that panix.com was held in the .com registry that does not use the new EPP protocol which incorporates the facility to store a separate password (called auth_info) for each domain name that must be checked before completing a transfer.

Transfers Process
(see Policy on Transfer of Registrations between Registrars for full details)

(1) A person initiates a transfer for a domain name via a reseller or registrar

(1a) For registries (e.g org, biz, info, name) that use the EPP protocol, the person also needs a password that is held in the registry for each domain name (called auth_info in EPP protocol)

(2) The gaining registrar is responsible for obtaining approval from the registrant (using the contact details available in the WHOIS of the losing registrar) using a standardized form. In some cases registrars delegate the obtaining of the approval from a reseller that has direct contact with the registrant. A gaining registrar is not permitted by the policy to initiate a transfer without approval from the registrant.

(3) The registrar initiates the transfer.

(4) The registry checks to see if the name is on Registrar-LOCK, if so, the transfer request is rejected. Registrants may choose to put domain names on registrar-lock. Many registrars now put names on lock by default, and give the registrant the opportunity to remove a lock prior to transfer.

(4a) For registries (e.g org, biz, info, name) that use the EPP protocol, the registry checks the auth_info supplied by the gaining registrar against the record in the registry. If there is no match, the transfer request is rejected.

(5) The registry will send a message to the losing registrar confirming that a transfer has been initiated.

(6) [OPTIONAL] A losing registrar may send a standard confirmation message to the registrant. A registrant may cancel a transfer at this point. A registrant may also immediately confirm a transfer at this point and the transfer will be immediately completed.

(7) If the registry receives no response from the losing registrar after a 5 day period, the transfer will be completed.

(8) A registrant may not further transfer a name for a period of 60 days (apart from back to the original registrar).

(9) If the losing registrar believes that a transfer was unauthorized, the losing registrar may contact the gaining registrar for a copy of the authorization in step 2 to arrange for the transfer to be reversed.

(10) If the registrars cannot resolve a dispute, the losing registrar may initiate a dispute process with the registry operator.

(11) If the registry operator cannot resolve a dispute, the losing registrar may initiate a dispute process with an external dispute resolution provider.

In the case of panix.com, the step (2) failed at the gaining registrar. I can’t comment on steps taken by the losing registrar.

The principle of the process is that a registrant can move to another domain name provider (registrar or reseller) at any time, and can initiate a transfer from the new provider. This relies on the new provider authenticating the request. Losing registrars can incorporate registrar lock and transfer confirmation messages to minimize the risk in this process.

The integrity of the process is greatly improved through the use of the auth_info password in the EPP protocol. This has been operating effectively in .org, .info., .biz and .name.

The alternative to the process could be for the losing registrar to authenticate and initiate a transfer away. This may be more secure, but has a downside in that a losing registrar has an incentive to make this process as difficult and slow as possible.

The current transfer policy was a result of over 2 years of work, but can always be improved. Thus ICANN is currently conducting a review of the policy.

My personal view is that the current transfer policy WITH the use of auth_info and with the use of registrar-LOCK is a reasonable balance between security and allowing registrants to easily move their name.

Areas for further improvement include having an expedited process for managing a fraudulent transfer—including the ability to quickly revert back to the previous DNS information while a dispute is investigated, and having mechanisms to ensure that 24/7 emergency contacts are available for all registrars at the registry.