North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Gtld transfer process
- From: Alexei Roudnev
- Date: Tue Jan 18 03:49:43 2005
Problem - you are talking about changing registrar, but in reality you
describe changing of domain owner.
Why (what for) is it allowed to transfer from one registrar to another with
changing NS records and other owner information?
Why don't separate this 2 events - changing registrar, and changing domain
owner/information? Is it any need in reality changing registrar with
simultaneous changing domain information?
What should happen in normal situation:
- someone requested transfer of domain (without real authorisation);
- even if all checks pass and transfer was allowed, new registrar should
maintain the same NS and other information as old one, so no real damage
- domain owner received e-mail, see frauded transfer and disputed it (having
domain in working condition on the new registrar);
- new registrar OR old registrar OR VeriSign roll back transaction.
----- Original Message -----
From: "Bruce Tonkin" <Bruce.Tonkin@melbourneit.com.au>
Sent: Monday, January 17, 2005 11:36 PM
Subject: Gtld transfer process
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.
(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
(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
(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
(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
(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
(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
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.