Introduction: ICANN's Alternative Path to Delegation (Part 1 of 4)

By Dr. Burt Kaliski Jr.
Dr. Burt Kaliski Jr.

As widely discussed recently, observed within the ICANN community several years ago, and anticipated in the broader technical community even earlier, the introduction of a new generic top-level domain (gTLD) at the global DNS root could result in name collisions with previously installed systems. Such systems sometimes send queries to the global DNS with domain name suffixes that, under reasonable assumptions at the time the systems were designed, may not have been expected to be delegated as gTLDs. The introduction of a new gTLD may conflict with those assumptions, such that the newly delegated gTLD collides with a domain name suffix in use within an internal name space, or one that is appended to a domain name as a result of search-list processing.

Verisign Labs conducted two research studies earlier this year on the evidence for and risks of potential name collisions between installed systems and applied-for gTLDs. The studies confirmed that a large number of queries currently processed by the DNS root servers do indeed include domain name suffixes that match applied-for gTLDs and therefore could be at risk if the behavior of the global DNS were to change.

Without appropriate countermeasures, changing the global DNS by delegating a new gTLD could introduce significant cybersecurity and operational risks, as explored further in two recent Verisign Labs Technical Reports: New gTLD Security and Stability Considerations and New gTLD Security, Stability, Resiliency Update: Exploratory Consumer Impact Analysis. For example:

One way to classify techniques for mitigating the risk from name collisions is into two broad categories:

This categorization is convenient because techniques in the two categories can complement one another: Installed systems could be remediated so that they avoid some of the queries that could put them at risk, and the operation of the new gTLD could then be constrained so that the response remains the same for the rest of the queries.

ICANN has recently proposed a new technique in the second category: second level domain (SLD) blocking. Rather than completing a full name collision risk analysis prior to delegation, the applicant for a new gTLD who accepts the "alternate path” of SLD blocking simply agrees not to register any SLDs associated with the new gTLD in the "Day-in-the-Life of the Internet" (DITL) and other relevant data sets. The intent is that responses to queries for domain names with such SLDs will remain the same as prior to delegation: the global DNS will still indicate they don't exist. The risk of name collisions for those queries, it is hoped, will therefore be mitigated.

The problem, as is often the case for new proposals, is in the details. In the next three blog posts, I will outline three main concerns with ICANN's alternative path to new gTLD delegation:

Part 2 of 4 – DITL Isn't Statistically Valid for This Purpose
Part 3 of 4 – Name Collision Mitigation Requires Qualitative Analysis
Part 4 of 4 – Conclusion: SLD Blocking Is Too Risky without TLD Rollback

By Dr. Burt Kaliski Jr., Senior VP and Chief Technology Officer at Verisign

Related topics: Cybersecurity, DNS, Domain Names, ICANN, New TLDs