ICANN73 took place last week and, as always, it was a productive conference. Panels covered an interesting range of topics: in-progress policy work, what it truly means for something to be in the global public interest and how ‘public interest’ can be assessed, what’s next for new gTLDs now that the Subsequent Procedures Working Group recommendations are final, and, of course, the always-essential DNS Abuse work.
I recently did a deep dive into a specific and esoteric policy question, so for our ICANN73 review, I’m going to focus specifically on the policy work that will (eventually) be relevant to our resellers and registrants and then take a look at a new area of focus in the ongoing work to address DNS Abuse: the difference between a maliciously-registered domain and a compromised website, and why it matters.
Policy work: what you need to know
Transfer Policy Review Working Group recommendations
When I joined the Tucows team almost five years ago, one of my goals was to help improve the registrar transfer process. This was perhaps not the most realistic choice, since it’s not something I can personally make happen; as regular readers know, the policy development process is highly structured and changes take years to come into effect. Still, being a member of the Transfer Policy Review Working Group for the last year has been extremely satisfying.
Transfer Policy requirements are divided up into three phases; our current Phase 1a includes the Transfer Authorization Code, Gaining and Losing Forms of Authorization, transfer denials, and some aspects of bulk transfers. We’ll work through these topics before moving on to the Change of Registrant process in Phase 1b, and then Phase 2 will cover the Transfer Emergency Action Contact, the Transfer Dispute Resolution Policy, and the remaining aspects of bulk transfers.
Here’s a quick rundown of where the team has landed on Phase 1a issues so far:
Transfer Authorization Code
What is it? A code that the domain owner gets from their current registrar and provides to the new registrar to authorize the transfer of their domain name.
What’s changed?
- Now called the “Transfer Authorization Code (TAC)”; no more AuthInfo Code, EPP Code, EPP Key, Transfer Auth Code, or Transfer Key/Code. Just the TAC.
- The TAC will not always exist; it’s created upon request, can only be used once, and will expire after 14 days (or upon use).
Gaining Form of Authorization (FOA)
What is it? A confirmation email sent by the gaining registrar as part of the transfer process.
What’s changed?
The Gaining FOA is officially no longer required. This has been the operational reality since we started working under the Temporary Specification in May 2018 (post-GDPR), and the Working Group has decided to maintain this for the long term by eliminating the Gaining FOA.
You may wonder how the transfer gets confirmed, if not via the Gaining FOA. The new process will be that the domain owner obtains the TAC from their current registrar and then requests the transfer with the new registrar, providing the TAC to prove that they have authority over the domain. The transfer will be completed immediately when the TAC is provided; there will no longer be a five-day pending-transfer delay built into the process. This streamlines the domain owner’s experience, removing the five-day pending-transfer delay that was so often a source of frustration and annoyance.
Losing Form of Authorization (FOA2)
What is it? A confirmation email sent by the losing registrar as part of the transfer process.
What’s changed?
- The Losing FOA is no longer required in its current form, as the transfer completes automatically as soon as the gaining registrar submits the request along with the TAC to the registry.
- Instead, when the losing registrar provides the TAC to the domain owner, they must also send a new “Notification of TAC Provision” email that includes the domain name, the date and time the TAC was provided, and instructions for what to do if the TAC request was invalid.
- This notice could also include the TAC itself, depending on how the registrar’s system is set up. The purpose of the notice is to ensure that the domain owner is aware that the TAC has been obtained and allow them to contact the registrar if it was sent out in error.
- If the TAC is provided via a control panel, then the notification must be sent via email, but if the TAC is provided via email there’s no need to send two separate notices; they can be combined into one.
- Unlike the Forms of Authorization, this new Notification of TAC Provision is not a strict template; instead, the policy will provide a list of required elements and allow each registrar to present the text in the way they think will be most helpful to their users.
This updated process maintains a high level of security by introducing important protections at the start of the transfer: the current registrar must confirm that the request is valid and also ensure that the domain owner is aware that the TAC has been provided, so they have the option to contact the registrar if there’s an issue.
As regular readers know, once the policy recommendations are finalized by the Working Group, they need to be approved by the GNSO Council and then the ICANN Board before going to an Implementation Review Team that turns them into actual policy. Then, there’s an implementation buffer period of at least 6 months from the time the final policy is published to when it comes into effect and we need to follow it. With that in mind, the changes outlined here are some years away from going live, as we are still in that first step. If you have feedback about what you’ve read here, or ideas for how the transfer process should be improved, I’d love to hear about it!
Expedited Policy Development Process (EPDP) for gTLD Registration Data
Phase 1 Implementation Review Team (IRT)
We haven’t written about the Phase 1 IRT since ICANN70, but the work has certainly progressed since then, and the new Registration Data Policy is almost final.
Implementing the EPDP recommendation relating to the Registrant Organization field was started but then put on hold, as the Board had not fully approved the recommendation. Their concern was that allowing registrars to delete data from the Organization field (under very specific circumstances) could result in domains with no listed owner. The GNSO Council addressed this by supplementing the recommendation with guidance, saying that before the Organization data is deleted, the registrar must make sure there’s a full name in the Registrant Name field, and the Board has now approved that updated recommendation. With that decided, we can now fully implement this Recommendation. The other significant remaining piece is the Data Protection Agreement between ICANN and the Contracted Parties, which everyone hopes will be completed soon.
We expect the policy language to be published for public comment in Q3 of this year and aim to incorporate feedback and publish the final report in Q2 2023. Then, there will be a long implementation window, from Q2 2023 to Q4 2024, with the policy going into full effect by the end of 2024.
EPDP Phase 2 & 2a Updates
The Phase 2 Recommendations relating to the Standardized System for Access and Disclosure (SSAD) of gTLD registration data remain with the Board for consideration, and there’s a small team working with the GNSO Council to help them review the Operational Design Assessment; for details, take a look at my recent blog post on the topic.
Phase 2A of the EPDP focused on two specific topics, and the recommendations from that Working Group have now been adopted by the Board. I won’t get into the nitty-gritty details (email me if you want to hear more!), but the final recommendations affirm the decisions from previous phases:
-
- Registrars and registries are permitted but not required to treat different types of domain owners differently (legal persons vs. natural persons).
- Those registrars and registries that choose to publish a pseudonymous contact email for domain owners (rather than the webform option, which Tucows chose for the data protection and anti-spam benefits) are not obligated to use the same pseudonymous contact email for all domains with the same real registrant email address.
For both topics, guidance has been provided, which may help contracted parties adhere to relevant data protection laws.
DNS Abuse
ICANN73 also included a plenary session discussing the difference between domains registered with malicious intent and those that are purchased for legitimate reasons but are then compromised and used to do bad things. This is a necessary distinction, as each of these categories requires a different type of response from the direct service provider and registrar. For example, if only a mail service or single email account has been compromised, taking an entire domain offline makes all of the other assets tied to that domain, including the website, inoperable. The conversation was illuminating and we recommend that you watch it.
In addition, the Registrar and Registry DNS Abuse Working Group has convened a subgroup to examine this issue and Tucows is, of course, participating in that group. The current focus is creating an informational document explaining the difference between compromised and malicious domains, along with what to do for each.
Tucows is always committed to working with our resellers to combat DNS Abuse. When we receive a report of a potentially-compromised domain, we reach out to help you help your customers. We are pleased to participate in the DNS Abuse mitigation subteams and contribute to the security and stability of the Internet.