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 could happen; - 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> To: <nanog@merit.edu> Sent: Monday, January 17, 2005 11:36 PM Subject: Gtld transfer process 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