Thursday 30 June 2022
ICANN’s Transfer Working Group has created an Initial Report about recommended changes to how domain transfers work. The Transfer Policy governs the procedure and requirements for registrants to transfer their domain names from one registrar to another. The goal is to provide for enhanced domain name portability, resulting in greater consumer and business choice.
Currently, the gTLD transfer process works as follows:
1. The Registrant gets an authorization code from the losing registrar and provides it to the gaining registrar
2. Gaining registrar verifies the transfer request and initiates transfer
3. Losing registrar sends notice (a “Form of Authorization, or FOA) of a pending transfer to the customer, giving them up to 5 days to cancel the request.
Efficiency Over Security?
Step 3 gives the Registrant 5 days to cancel the transfer in case the domain name was hijacked by an unknown party. One of the key changes recommended in the report was to remove step 3. Instead, a notification would be added in Step 1, the issue being that a domain name could be transferred within minutes of it being initiated. This 5-day period gives Registrant the opportunity to identify fraudulent transfer attempts within a reasonable timeframe.
popular domain name blog, Domain Name Wire summarised it best:
While this will make transfers easier and — in the words of the Initial Report — instant, I’m concerned that it will result in fraudulent transfers.
It would be interesting to hear from registrars about how many times customers try to stop fraudulent transfers after receiving the FOA.
Transfer Out Fee: Charging customers to move away
A Registrar may not withhold a domain name transfer; however, we have seen some Registrars charge their customers significant fees for moving their domain names away. These fees are not standard within the industry and normally relate to terms tucked deep within an agreement. We have seen invoices in some cases in the tens of thousands of dollars and do not add any value to the customer. They seem to be arbitrary fees for the effort of assisting a Registrant to move away.
It is our view that Registrants should not be forced to pay “exit” fees when they are trying to move to a new Registrar that better suit their needs. We have reviewed such a third-party agreement, and the terms were ambiguous at best, but without a clear policy to deal with this issue, it creates an opportunity for some Registrar to use transfer out fees as a tool to deter their clients from leaving.
If the goal of the transfer policy is to provide for enhanced domain name portability, resulting in greater consumer and business choice, then these fees fly in the face of this fundamental principle and should not be allowed.
A Registrant should not feel stuck with their Registrar due to obscene transfer away fees
ICANN has created this transfer policy to prevent obstacles around choice and portability but has not addressed these specific issues arguing that commercial matters are between the Registrar and the Registrant.
Recommendation 22 is looking to update and revise the Transfer Policy so that situations in which a Registrar may not deny a transfer request are instead situations in which the Registrar of Record must not deny such a request. Brandsec supports this policy update, however, we believe that the policy should be taken further and prohibit commercial arrangements that inhibit the portability of domain names in the first place.
Even if Recommendation 22 is approved, it does not address the issues of the transfer out fee, which in itself is enough to deter Registrants from transferring their domain names. They are effectively commercially shackled to their Registrar in perpetuity unless they pay, in some cases very large sums of money, to leave. Transfer out fees only benefit the Registrar and this practice should not be allowed in our industry.
Recommendation 22 should be updated, and approved, to reflect this.
Other Proposed Recommendations
Other Recommendations included:
- Eliminate the requirement that the Gaining Registrar send a Gaining Form of Authorization;
- Eliminate the requirement that the Losing Registrar send a Losing Form of Authorization;
- Require the Registrar of Record to issue a Notification of Transfer Authorization Code (TAC) Provision to the Registered Name Holder within ten minutes of providing a TAC;
- Require the Losing Registrar to send a Notification of Transfer Completion to the Registered Name Holder within 24 hours after the transfer is completed;
- Replace “AuthInfo Code” and similar terms (Auth-Info Code, Auth-Code, transfer code) with “Transfer Authorization Code” (TAC) throughout the Transfer Policy;
- Define “Transfer Authorization Code” as: “a token created by the Registrar of Record and provided upon request to the RNH or their designated representative. The TAC is required for a domain name to be transferred from one Registrar to another Registrar and when presented authorizes the transfer.”
- Task ICANN org with the creation of minimum requirements for and components of the TAC;
- Require Registries to validate that a TAC meets the minimum requirements when it is stored in the Registry system;
- Secure the TAC process by: only generating a TAC upon request, securely storing the TAC in the Registry system using a one-way hash, and provide information regarding the timing of expiration of the TAC;
- Affirm the Temporary Specification’s requirement that the Registry Operator verify that the TAC is valid prior to allowing an inter-registrar transfer;
- Require that each TAC be a “one-time use” code;
- Maintain the existing requirement that registrars must provide a TAC within “five calendar days” of a request, but recommend changing the time limit to 120 hours for clarity.
- Set a default Time to Live (TTL) for a TAC at 14 days, and allow the Registrar of Record to set the TAC to null before the expiration date upon request from the Registered Name Holder or by agreement between the Registrar of Record and the Registered Name Holder;
- Clarify what terms are equivalent between the Transfer Policy and the current Registrar Accreditation Agreement by specifying (for example) that “WHOIS Data” and “Registration Data” are referring to the same thing;
- Remove any reference to “Administrative Contact” or “Transfer Contact” and replace those terms with “Registered Name Holder” unless specifically indicated;
- Establish a mandatory 30-day moratorium on transfers from the initial registration date;
- Establish a mandatory 30-day moratorium on new transfers from the date of completion of an inter-registrar transfer;
- Separate section I.A.3.7 of the Transfer Policy into two distinct sections, one containing the requirement that the Registrar of Record present their reason for denial of a transfer request, and the other specifying the permitted reasons for denial;
- Update and refine the language of the permitted reasons for denial of a transfer request;
- Update and revise some of the reasons that the Registrar of Record may deny a transfer request under the Transfer Policy so that they become circumstances under which the Registrar of Record must deny the transfer request;
- Update and refine the language of the Transfer Policy’s existing list of circumstances under which the Registrar of Record must deny a transfer request; and
- Update and revise the Transfer Policy so that situations in which a Registrar may not deny a transfer request are instead situations in which the Registrar of Record must not deny such a request.
About brandsec
brandsec is a corporate domain name management and brand protection company that looks after many of Australia, New Zealand and Asia’s top publicly listed brands. We provide monitoring and enforcement services, DNS, SSL Management, domain name brokerage and dispute management and brand security consultation services.
