The ICANN83 meeting in Prague, Czechia, brought the Community together for four days of policy-focused sessions. Contrasted with other ICANN meetings, which include a Public Forum, Annual General Meeting for the Board, and other more business-oriented sessions, the Policy forum centers on current policy and implementation work, so it’s usually the most jam-packed for the policy enthusiasts among us. In this recap, we’ll check in on the topics we’ve been tracking and look at what may be on the horizon for the domain industry.

DNS Abuse

This topic gets top billing because Tucows’ own Sarah Wyld hosted the Registrar Stakeholder Group (RrSG)’s DNS Example Review & Discussion session and had so much fun that she’s now considering leaving everything behind to start a new life as a daytime game show host. This session featured a panel of representatives from groups across the ICANN community who were presented with example reports of DNS Abuse and asked to indicate what they thought the best outcome would be. Audience members contributed their input via a Zoom poll and discussion, and the conversation was robust and lively.

Overall, there was strong shared understanding that DNS Abuse needs to be stopped or otherwise disrupted (as it says in our contract!), but also a recognition that not every bad thing that happens on the Internet is DNS Abuse, which is defined as phishing, pharming, malware, botnets, and spam when used to deliver the other four types of Abuse.

More broadly, the big conversation happening throughout many sessions at ICANN83 was around what anti-Abuse measures would be appropriate for codification into Policy now that the Registrar Accreditation Agreement (RAA) and base Registry Agreement (RA) have been amended to include enhanced requirements for Registrars; the good news is that lots of people have ideas and lots of those ideas are pretty similar—so we should be able to agree on a path forward.

The Contracted Party House (Registrars and Registries) held a Community Update session where they proposed four areas of work that could be appropriate for a Policy Development Process (PDP). These work streams are specific and narrowly-targeted to help ensure that the work has a real measurable impact and can be completed in a timely manner; the idea is that as each PDP moves from the Working Group to the Implementation Review Team, the Working Group can begin to tackle the next, which should help make the whole process more efficient. 
The work streams proposed by the CPH can be reviewed in detail in their slide deck; at a high level, they are:

  • A requirement to pivot on well-founded reports of malicious registered domains: reviewing other domains in the same account or owned by the same person when investigating an actionable report of DNS Abuse
  • API/reseller agreement mandatory clauses: updating the RAA to include clear obligations for how Resellers would address DNS Abuse 
  • Mitigation of batch-registered domain names generated by a botnet algorithm: considering the creation of a clearinghouse, a central collection and distribution point of verified lists of algorithmically-generated domains that can be used by gTLD registry operators 
  • Best practices for reporting phishing: taking current practice and elevating it to Policy, enabling those who report DNS Abuse to do so in the most useful way possible.

This conversation is not without its difficulties. Alan Woods of CleanDNS wrote about one presentation given to ICANN’s Governmental Advisory Committee (GAC) that highlighted some of the pitfalls often encountered in efforts to address DNS Abuse. We share Alan’s concerns and hope that, as the work progresses, we’ll make data-driven and well-considered Policy decisions.

Registration Data

Registration Data Request Service (RDRS)

The Standing Committee met twice to continue work on Chapter 4 of their report, considering what should happen with the recommendations from the EPDP Phase 2 on the Standardized System for Access and Disclosure of previously-public gTLD registration data. Some of these recommendations have been partially implemented in the Registration Data Request Service (RDRS), including:

  • Recommendation #3, which standardizes the format and contents of requests
  • Recommendation #5, which determines what Registrars must include in a response (remember, providing a response does not necessarily mean disclosing data; it means making a determination and carrying it out by either disclosing the data or explaining why it cannot be disclosed)
  • Recommendation #15, which lays out requirements for logging requests and outcomes.

Other SSAD Recommendations are not at all reflected in the RDRS, most notably, the recommendations around accreditation of requestors—the RDRS lacks any form of requestor accreditation—and the financial sustainability of the SSAD. ICANN doesn’t charge any sort of fee to RDRS requestors. Instead, the RDRS is funded out of fees registrars pay to ICANN, which ultimately come from selling domain names. The SSAD, on the other hand, would operate on a cost-recovery model with fees paid by the requestors. We think that model would be much more appropriate, especially since the current cost-per-request has been calculated by ICANN at over $1000. A cost breakdown will be included in the Standing Committee’s forthcoming report.

Urgent requests for disclosure

The topic is back on the menu, as the Registration Data Policy Implementation Review Team (IRT) met to discuss the required timeframe for responding to disclosure requests that meet the definition of “urgent” and come from authenticated entities. Read more about it in our pre-ICANN83 TACO Stats blog.

Accuracy

This topic was on the GAC’s mind throughout ICANN83, and the GNSO Council has dedicated a Small Team to working through responses to their recent Registration Data Accuracy Survey. 

There are some key areas of alignment among the team members already: 

  • Accurate data is important to the Domain Name System
  • The starting point to define accuracy is the current RAA requirements
  • More information is needed to understand the problem space

We don’t disagree with these points and think they’re a good starting point, especially since there’s some confusion throughout the ICANN Community around what registrars and registries currently do to ensure registration data is accurate. Accuracy should mean that:

  • The registration data correctly reflects what the domain owner provided
  • The contact info is in good working order
  • The domain owner can be reached at the contact point provided (also called contactability)

The RrSG has provided documentation that gets into the details. Here at Tucows, we’ve offered privacy-maintaining contactability for domains for years. We’re also closely watching the implementation of NIS2 in EU countries and how impacted ccTLD registries are adapting their policies in response—many have already made or are planning to change their requirements for validating and verifying the accuracy of registration data. To learn more, check out our NIS2 blog post, which we update regularly.

PPSAI

The Privacy and Proxy Services Accreditation Issues (PPSAI) IRT meeting focused on accreditation models, although the group isn’t sure whether Privacy or Proxy providers should be accredited. It sounds like a good idea on the surface—registrars and registries are accredited, so why shouldn’t Privacy and Proxy providers also have rules to follow? But the reality is that it only makes sense in a very narrow set of circumstances, which don’t cover the majority of use cases.

Sure, the domain registrar may be the Privacy provider, so they already have a relationship with ICANN and could take on another type of accreditation. But what about a domain reseller? They have a contract with the registrar—will they now need to also sign up directly with ICANN? What about a trademark lawyer who buys every variation of “Batman On Ice” so that DC’s new project doesn’t go public ahead of schedule? What about the domain that I (an individual person, not a big business) bought for my sister’s recipe blog? I put it in my name so she doesn’t have to deal with renewal reminders, so now I’m a proxy provider; do I need to sign a contract with ICANN and pay for the privilege of sparing my sister the renewal reminders? The reality is a lot messier than most groups at ICANN seem to think, making accrediting Privacy or Proxy providers a bit of a pipe dream.

The IRT was brought together to answer some specific questions for the GNSO Council, but that work led to more questions, rather than answers. The group hopes to have a report summarizing their work ready by August, so between this and the RDRS Standing Committee’s report, we’ll have a lot of summer beach reading ahead of us.

Work with the Security and Stability Advisory Committee (SSAC)

One thing that’s been on our minds for a few ICANN meetings now is that the CPH (Registrars and Registries, together the Contracted Party House) could do more to build our relationship with ICANN’s Security and Stability Advisory Committee (SSAC). This would allow us to share insights and expertise and learn from each other, ensuring policy recommendations consider security from the very start. 

At ICANN83, the CPH and SSAC met to share information about their current work; the SSAC spoke about their new publication, SAC127 DNS Blocking Revisited. DNS Blocking (as you may guess from the name) means restricting access to a domain and its related resources (email, website, etc.) by altering the DNS in some way, such as indicating a domain doesn’t exist when it actually does, or sending the user to a different end location than what they asked for. 

While there may be security benefits to this— such as diverting traffic from a malicious website or restricting content in certain locations, like schools—it breaks the chain of trust because the user cannot be sure that they’re seeing the DNS resource they requested. The CPH raised questions around trust and responsibility; how can we achieve security goals while not supporting censorship and fragmentation of the Internet?

DNS Blocking is a tool which, like other tools, can be used for good or for ill; who’s responsible for ensuring that it’s used for good? The SSAC suggested that in-browser notifications would explain when DNS Blocking or redirection has occurred, but that assumes that the user will understand the message and that browsers will take the initiative, neither of which is guaranteed. 

We had many productive discussions in Prague and came away with a number of ideas and work items that we’ll address in the time leading up to the next ICANN meeting in October. We hope to see you there!