ALAC Members: Steinar Grøtterød and Daniel Nanghaka
ALAC Alternates: Raymond Mamattah and Lutz Donnerhacke
ALAC Observers: Chokri Ben Romdhane, Hans Bathija, K Mohan Raidu, Sivasubramanian Muthusamy
See: Workspace of the Transfer Policy Review PDP
Transfer Policy seen by Registrants
This chapter is intended to be present as a separate document to the PDP process. It should describe the position of the domain name holder (registrant) in the process of a domain transfer or owner change.
Visible Roles and Communication
The registrant does have a contract with his reseller, which does all the work on the domain name for him. In some case the reseller works also as the DNS-operator, in other cases DNS is self-hosted by the registrant (end customer).
The registrant usually does not know which registrar is handling the domain registration and who is running the registry and/or the RDDS-database. All communication is done via the reseller. Hence any communication bypassing the reseller may cause confusion or is completely lost, unless the reseller is informing the registrant beforehand. That's why any policy should state clearly, which direct communication may occur in which situation, so that the reseller is able to attract the registrants attention to it early and clearly.
The registrant is not allowed to verify it's own RDDS entry by himself. Registrant relies on the reseller on this subject. Maybe there should be a policy to gain access to the full record for the registrant by a standardized method provided directly by the registry.
Inter-Registrar Transfer
The registrant asks the new (gaining) reseller to transfer the domain. He want's to switch the contractor. Often the change results from a bad mood between the old (losing) reseller and the customer (registrant). So the registrant does no want to talk to the old (losing) reseller, if possible.
Authinfo-Code
The gaining reseller tells the registrant to contact the losing reseller, ask for an authinfo-code, switch the domain into an transferable state: ACTIVE instead of LOCKED, and to hand over zone file data. If the losing registrar finds reasons to deny the authinfo code, the regsistrant is in a bad position. How can the registrant enforce an handover of the authinfo code, even if the reseller is unwilling or unable to help? A typical example is a reseller, which was going out of business or try to get some disputed invoices paid.
Gaining FOA
In order to start the transfer, the registrant has to formally start the process (for a paper trail), but reseller does not have access to the RDDS data and therefore can not verify this formal document (called gaining FOA). The only information, the reseller needs to know is the authinfo code, which is sufficient to start the process at the registry by the registrar (commanded by the reseller). So, can the gaining FOA be removed at all? Most registrants are not aware of the gaining FOA either.
Losing FOA
If an transfer process is started by the gaining registrar, the losing registrar sends a losing FOA directly (not via the losing reseller) to the registrant. This way the registrant could check, that the process is legitimate and started by the correct parties. How can the registrant be empowered to take the unknown, unexpected messaged in a foreign language serious?
Unfortunately the losing FOA does only mention the gaining registrar, which is mostly unknown to the registrant. Can the losing FOA mention the gaining reseller, too?
From the interests of the registrant, can the losing FOA be removed at all, because it's too similar to spam?
Risk of lost authinfo-codes
The authinfo code is usually send via unencrypted email from the losing reseller to the registrant. Even inhouse the authinfo code is mostly handled carelessly by the registrant. There is a good chance to obtain the authinfo code may be leaked to an attacker. The attacker can use the authinfo code to start the transfer earlier, than the registrant itself. How can the registrant notice such an impersonation fraud without a losing FOA? Which data must be included into the losing FOA to prevent this type of attacks?
Change of Registrant (aka Owner Change/COR)
Typically the registrant asks its reseller to change the owner related data, if something needs to be changed. The reseller does obtain such information from the change of contractual data with the registrant, and updates the RDDS automatically via the registar interface. In the case, the losing registrant want's to transfer the ownership of a domain to a different enitiy (gaining registrant), the process is initiated by the losing registrant itself.
Notification about changes
If RDDS of the domain is changed, the registrant will not notice the change without explicit notification by the reseller. Especially private, single domain registrants will not and can not understand the messages from a registry or registar. They consider those unknown and unexpected sources as spam. Only the well known reseller has the ability to reach the attention of the registrant. So an impersonation of the domain may be stay for a long time. Most common examples are web developers or small IT companies, who register the customer domains to themselves. How can the registry inform the registrant about an owner change effectively? May the registrant need to respond actively?
Of course, larger registrants are much more able to do their own domain management.
Verify of correct current data
ICANN requires a regular check of the accuracy of RDDS. The emails send to the registrants are designed to be accepted by not responding. Because most of them are considered as spam, the whole process is broken by design. How can the registry get in touch with the registrant in order to actively validate the accuracy of registration data regularly?
Loss of domain due to fraudulent change of ownership by the reseller
Because the registrant is often uninformed and ignorant to its own domain ownership, a fraudulent change of ownership is easily successful. Registrants will not notice the loss of their own domain as long as the typical operations are still working. Even a change of MX to intercept communication will not be noticed by the registrant but only by the operator of the mail services. How can the we raise the awareness of the registrant about domain ownership?
60 day lockdown period
If a domain is transferred or the ownership was changed, the 60-day lock is enabled to protect the registrant from fraudulent changes. We at AtLarge do not understand the thread model behind this lock clearly enough, so how should the innocent registrant understand the reasoning to slow down the process of updating a domain to a new situation. In many cases the information provided by the registrant is incomplete and erroneous, so that the reseller has to update the domain several times. The 60-day lock actively stops him from setting the correct data. What is the reasoning behind the 60-day lock and how can it be explained to the registrant?
- Survey responses and data provided by ICANN’s Global Support Center indicate that registrants do not understand the 60-day lock and express frustration when it prevents them from completing an inter-registrar transfer. (Information given in the Charter)
COR of Privacy-/proxy registrations
If a registrant uses a privacy/proxy services, they simply don't want to be found their contact details (provided on the website anyway) publically available in the net. They do not even understand the implications of using a privacy/proxy service: Does the privacy/proxy service factually own the domain? How can a privacy/proxy service be stopped from transferring the domain to a different owner? Who is responsible in the case of such fraud?
