The motivation for such a shift is, for example, dissatisfaction with the service or pricing policy of the current registrar. Also after company takeovers or mergers, the DNS is usually consolidated by transferring all domains to a single registrar. In November 2004 ICANN set up rules for domain transfers which are binding for all registrars and which are intended to simplify the process and make it more secure.
A domain transfer does not change the ownership of the domain concerned . Ultimately, only the entry in the registry database is changed that defines which registrar is responsible for this domain and its owner.
The starting point is always the end customer, i.e. the owner of a domain. His first point of contact is the future registrar, who then gets in touch with the current registrar via the responsible registry:
- The registrant (end customer) authorizes and legitimizes himself to the future registrar.
- The registrant requests the transfer for the domain to be relocated from the current registrar.
- The future registrar forwards the application to the higher-level registry (if necessary after additional confirmation by the domain owner).
- The registry contacts the current registrar and asks him to agree or reject it (if there is no response within five days, this is considered consent).
- The current registrar sends an email to the administrative contact person for the customers.
- The administrative contact person confirms the transfer (if no confirmation is received, this is considered a rejection).
- The current registrar forwards the confirmation or rejection to the higher-level registry.
- The registry carries out the transfer by changing its database.
If the transfer is handled as a service by a third party (e.g. a hosting provider), the latter can act as an intermediary between the registrant and the registrar and handle individual or all interactions with the registrars involved on behalf of the company. The registrant only has to give him the documents for legitimation and authorization.
In practice, this process is usually fully automated. The only manual processes are the formulation of the transfer application (step 2) and the confirmation (step 6) by the end customer. The communication between the registrar and the higher-level registrar usually takes place via the Extensible Provisioning Protocol .
In some cases, there are additional security measures to prevent an unauthorized domain transfer. In some domains (e.g., as .com, .net, .org, .info biz, .cn, .US, .LA, .pi, .name) is to provide a so-called authorization code (engl .: authorization code ) required to initiate a domain transfer. This sequence of 6 to 16 characters can be obtained from the current registrar on request. Some domains (e.g. .com, .net) can be in the registrar lock status . Before any changes can be made, the domain owner must cause the current registrar to set the status to active .
The transfer process, which appears clear and simple in theory, can turn into an administrative nightmare in practice. The main reason for this is out of date information in the domain database. For example, if the administrative contact person has already left the domain owner's company, consent to the transfer (step 6) is not easily possible.
Another potential problem is incorrectly or inadequately positioned name servers . The current registrar could, for example, have accepted that, contrary to the Internet rules, there is only one name server for a domain, but the future one requires at least two name servers and therefore rejects the transfer.
Since a registrar usually only earns little on a domain registered through him (often only a few cents up to euros per year), his willingness to resolve conflict cases through time-consuming manual rework is business-wise. This is especially true for the current registrar, who is losing a paying customer.
New since June 1, 2012
Registrars with ICANN -Akkreditierung must provide an emergency contact for urgent communications relating to transfers. This contact must be a physical person or a team and must not consist of automated systems. Responses must be received within four hours of the initial request, although the final resolution of the incident may take longer.