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:

• When a colliding gTLD is delegated, the name server for the gTLD might direct installed systems to resources in the global name space in response to a DNS query, rather than indicating that a domain does not exist. If this were to happen, resources within the installed system would be connected unexpectedly with resources outside, possibly leading to operational instability and potentially opening the door to attacks.
• Name collisions resulting from new gTLDs could also result in vulnerabilities based on internal-name certificates, which sometimes employ domain names with suffixes that were intended only to be assigned internally. If colliding gTLDs were delegated in the global DNS, a certificate obtained externally could potentially be misused to impersonate a user or a server within the internal network. ICANN’s Security and Stability Advisory Committee (SSAC) has recommended that certificate authorities transition away from issuing such certificates if potentially colliding gTLDs are involved.

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

• Remediating installed systems so that they avoid queries to the global DNS that could put them at risk if the response were to change when the gTLD is delegated (“at-risk queries”), or so that they handle the responses to such queries more carefully.
• Constraining the operation of the gTLD so that responses that could put installed systems at risk if changed remain the same as they were prior to the delegation of the gTLD.

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