Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Gtld transfer process

  • From: Bruce Tonkin
  • Date: Tue Jan 18 02:37:41 2005

Hello All,

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 analysing 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 http://www.icann.org/transfers/policy-12jul04.htm 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 standardised form
(http://www.icann.org/transfers/foa-auth-12jul04.htm).  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
(http://www.icann.org/transfers/foa-conf-12jul04.htm) 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 unauthorised,
the losing registrar may contact the gaining registrar for a copy of the
authorisation 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
(http://www.icann.org/dndr/tdrp/approved-providers.htm).


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 minimise 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 transfers 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 http://www.icann.org/announcements/announcement-12jan05.htm.

My personal view is that the current transfers 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.

I am interested to hear what members of the NANOG list believe would be
a better transfers process.

Regards,
Bruce Tonkin




















Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.