ICANN81, hosted in Istanbul, Türkiye, brought us together both in person and virtually for a week of working meetings and presentations. Before we get into the specific policy work updates, we want to highlight two important discussions happening within the ICANN community right now.

Perhaps closest to our cow-print hearts, ICANN Registrars and Registries (together, the Contracted Party House: CPH) are in the process of selecting someone for ICANN Board Seat 13, the CPH Board seat. We have the difficult task of choosing between several excellent candidates, all of whom would bring years of experience and unique areas of expertise to the role. Tucows’ own Reg Levy is in the running, and we believe she would fulfill the role admirably. As Reg expressed in her Candidate Statement, her years of experience on both registrar and registry teams, her willingness to calmly approach difficult topics, and her dedication to preserving the Free and Open Internet make her ideal for the role.

We also want to highlight that the ICANN Community is working through issues around efficacy and legitimacy; there is a perceived lack of trust in the multistakeholder model, which likely has two root causes. First there is a communications challenge: how can we demonstrate to the world that the multistakeholder model is the best model for Internet governance when our work is not always easily visible; how can we better showcase our successes? Second is the critique that ICANN’s processes could be made more efficient and our projects better prioritized: should we put another year into the RDRS project? Should we ask people to spend many hours in meetings on ICANN’s continuous improvement reviews? What really is the best way to measure the effects of the DNS Abuse contractual amendments, so we can decide what direction to focus on next? 
The multistakeholder model may not be perfect, but Tucows continues to believe it is the best way to govern our global Internet, ensuring that important questions like these are explored from various perspectives and that a wide range of concerns and priorities inform policy outcomes— an opinion which is supported by a recent paper published by the Australian government.

Registration data

The Registration Data Request Service (RDRS) continues to be a topic of interest. The Standing Committee, which has been managing the RDRS pilot project, met at ICANN81. Additionally, several groups within the ICANN Community discussed the RDRS project with the ICANN Board. 

The goal of the RDRS pilot project is to gather disclosure request volume data to help the Board decide if a permanent and more feature-rich system is worth building. The pilot has run for a year, half of its planned lifetime, and it seems that the Board may already have enough data to make an informed decision. We’re gratified to hear that the data collected so far has proven useful and we look forward to the Board’s decision about a long-term system. Tucows has been participating in the RDRS project while also, of course, continuing to use our TACO platform to manage and track registration data disclosures for the domains on our registrar platforms. We published a TACO stats update just before ICANN81. 

Another substantial piece of work happening right now is the ongoing implementation of the Registration Data Policy. We’re currently in the period where registrars and registries are permitted to make changes to our live systems, in preparation for achieving full compliance by August 2025. As always, Tucows is working to implement the necessary changes in a way that avoids work for our resellers. At this point, we don’t anticipate resellers having to make API changes.

Finally, the Registrar Stakeholder Group (RrSG) hosted a listening session on Registration Data Accuracy. Participants broke into groups where each was assigned a specific Internet user perspective—Registrant, Internet Service Provider, Business, Security organization, or Law Enforcement—and were asked to consider a series of questions: 

  • What does it mean for registration data to be accurate?
  • What concrete effects have we seen from inaccurate data, how is it stopping legitimate things from happening?
  • What processes should be in place to ensure data is accurate? Do any of these processes pose risks of their own?

This session was intended to prompt discussion and understanding rather than formal inputs and the feedback from participants was quite positive. The hope is that this shared foundation will inform how we all approach the topic in future work. 

Sessions to watch: Registration Data Request Service (RDRS) Update; RDRS Standing Committee Work Session; GAC Discussion on WHOIS and Registration Data Issues; Joint Meeting: GAC and CPH; GNSO RrSG & ICANN: Perspectives on Accuracy

Transfer Policy

We wrote about the Transfer Policy after ICANN79 and then more recently as we prepared our public comment on the Initial Report. The Working Group is now in the process of finalizing their Recommendations and issuing a Final Report. The first step is to review all comments submitted in response to their Initial Report, paying close attention to any new information or inputs they had not previously considered. Tucows wants to ensure a smooth and simple transfer process for registrants while also protecting against domain highjacking; the changes proposed by the Transfer Policy Working Group will strike a good balance and we are supportive overall. 

Sessions to watch: Transfer Policy Review PDP Working Group

DNS Abuse

The contractual amendments for DNS Abuse, which we wrote about following ICANN79, have been in place for most of a year now. On the registrar side, we’ve seen increased reports of DNS Abuse, including incorrect reports; this tells us that the DNS Abuse Amendments are known and that “take-down companies,” which detect and report cybercrime, are paying attention, a good thing overall. We have not yet seen an increase in evidenced reports and are working with the Registries Stakeholder Group (RySG) and the NetBeacon Institute to develop best practices around reporting. Better reports mean faster action.

The CPH DNS Abuse Subgroups and Non-Commercial Users Constituency (NCUC)  cosponsored a Human Rights Impact Assessment workshop around the DNS Abuse Amendments. What happens when an innocent registrant’s domain is hijacked and used to do something bad? How do all parties minimize the threats to the registrant’s human rights, including speech and assembly? It was an instructive session. Much like the Registrar Stakeholder Group’s “Good RDRS Requests” session at ICANN80, it was interactive and fostered dialogue between members with differing interests. Everyone learned from each other and came away with a better understanding of what everyone else had to deal with. We look forward to similar sessions at future ICANN meetings.

Tucows’ Reg Levy, co-chair of the RrSG DNS Abuse Subgroup, presented to the Governmental Advisory Committee (GAC) about the DNS Abuse Amendments. Some GAC members are quite interested in creating policies to further address DNS Abuse, but the specific focus and scope of these policies are unclear. We are, of course, committed to participating in well-scoped Policy work that helps to make the Internet better.

Sessions to watch: GNSO CPH & CSG Work Session; GAC Discussion on DNS Abuse Mitigation; DNS Abuse Updates; CPH DNS Abuse Community Update; GNSO: DNS Abuse Mitigation and Human Rights Impact Assessment

DNSSEC

Domain Name System Security Extensions (DNSSEC) was a topic of interest within the CPH TechOps team, in sessions hosted by the Security and Stability Advisory Committee (SSAC), as well as at the GAC.

The Domain Name System (DNS) was designed many years ago and, at the time, security was not the primary concern. This makes DNS more susceptible to certain types of security attacks. Here’s a simplified representation of one of these vulnerabilities, DNS cache poisoning, wherein a bad actor manipulates the DNS cache with malicious data to redirect a legitimate domain request to their own malicious website:

DNSSEC protects against DNS cache poisoning by using public key cryptography to verify the authenticity of the DNS data. With DNSSEC, any recursive DNS resolver that checks the zone retrieves the zone’s public key to verify the signature.

There are other attack scenarios where DNSSEC protects the integrity of the information, but discussing them all would be outside the scope of this post.

DNSSEC plays an important role in the security ecosystem but involves complex operations. CPH TechOps’ first session was dedicated to discussing these complexities and potential solutions. A presentation on Domain Connect, an open standard for DNS configuration where the DNS provider and the Registrar are not the same, detailed how this standard can be used to help with the process of DNSSEC in these third-party scenarios. DNSSEC automation and operations were also discussed in detail in the SSAC sessions. In addition, the SSAC held a three-session DNSSEC/Security workshop, focusing on deployment and automation.

DNSSEC has now been deployed by the majority of gTLD registries and is supported by registrars, as ICANN requires this in both its registry and registrar contracts. Unfortunately, the economics have not always favored DNSSEC. In this light, CPH Techops members discussed the security requirements for Web3 domains and how these may change the paradigm for DNSSEC. 

Tucows Domains encourages and supports the use of DNSSEC both on our registrar platforms and on behalf of our registry services customers.

Sessions to watch: CPH TechOps Working Session (1 of 2), SSAC Briefing to the Community, DNSSEC and Security Workshop (1 of 3), DNSSEC and Security Workshop (2 of 3), DNSSEC and Security Workshop (3 of 3)

Other areas of interest

We have been closely following discussions around Statements of Interest (see our ICANN76 and ICANN80 recaps) as we, like many members of the ICANN Community, find the existing disclosure requirements insufficient. Each participant in the ICANN policy development process must publish a “Statement of Interest” (SOI) disclosing their employer, location, and areas where they may have a material interest in the outcome of the policy process that could cause a conflict of interest.1 As of now, however, participants can simply put “private” instead of actually disclosing who their employer is, which does not achieve the goal of transparency.

We are pleased that the ICANN Board drafted a Community Participant Code of Conduct Concerning Statements of Interest and posted it for public comment. The new version states: “When disclosure cannot be made, the participant must not participate in ICANN processes on that issue.” We believe this to be the best and most appropriate way to address concerns about conflicts and will post a public comment to that effect within the next few days.

The other area of discussion right now is safety at ICANN. ICANN’s new Ombuds was introduced to the Community at ICANN81 and we hope that her experience in the field will be paired with the necessary independence to take action. Tucows is pleased to see this important step made toward fostering a safe and inclusive workplace for ICANN community members. We remain attentive to the topic of harassment and other inappropriate behavior within the ICANN community and look forward to meaningful improvement in reporting and response options; we will submit a comment to this effect on the Proposed Revisions to the Community Anti-Harassment Policy. The RrSG is also considering the best approach to deciding where ICANN Meetings are hosted, as the announcement that ICANN84 will take place in Oman spurred concern and conversation. We plan to discuss the topic with the ICANN team that works on safety and inclusion issues at ICANN Meetings. 

That’s our ICANN81 recap! We hope it was informative, and we’ll be sure to share further updates in the coming year.

  1. One such reason is that DNSSEC-protected zones are harder to maintain and could fail if signatures are allowed to expire or the secure delegation chain is somehow broken, issues that are not present in non-DNSSEC-protected zones. ↩︎