Recent comments on the name collisions issue in the new gTLD program raise a question about the differences between established and new gTLDs with respect to name collisions, and whether they’re on an even playing field with one another.

Verisign’s latest public comments on ICANN’s “Mitigating the Risk of DNS Namespace Collisions” Phase One Report, in answering the question, suggest that the playing field the industry should be concerned about is actually in a different place. The following points are excerpted from the comments submitted April 21.

In a previous comment, Eric Osterweil summarized key differences between established and new gTLDs as they affect name collision risks. Namespaces associated with established TLDs, he observed, represent “well known and measurable real estate” that system administrators can plan for. In contrast, namespaces associated with applied-for strings including new gTLDs, Osterweil continued, “inherently have no well-known policies and structure”—other than the assumption that they weren’t expected to be delegated in the future foreseeable to system administrators.

Osterweil’s points are important to keep in mind, because they apply just as much to one of the comments in this public review period as they did to comments in the previous period.

A better understanding of the situation starts with clear definitions. A name collision occurs when one system assumes that a name is in one name space, another system assumes that the name is in another name space, and the two systems interact unaware of their difference in assumptions. One of the reasons they may not be aware is that the assumptions of both systems were historically the same, and then the assumptions of one of the systems changed.

ICANN’s Security and Stability Advisory Committee (SSAC) expresses the definition as follows in SAC062:

“The term ‘name collision’ refers to the situation in which a name that is properly defined in one operational domain or naming scope may appear in another domain (in which it is also syntactically valid), where users, software, or other functions in that domain may misinterpret it as if it correctly belonged there.”

With this definition in mind, it’s useful to highlight two situations that are not the same as name collisions.

1. A change in the registrant for a domain name that already exists in the global DNS isn’t a name collision. Installed systems may get a different resource record in response to query after the change, but they’ve already assumed that domain names that exist in the global DNS are in an external name space; they don’t need to change their assumptions when the registrant changes. To counter one specific concern raised along these lines (see page 10 of this ICANN meeting transcript), the “retirement” of a domain name for which query traffic continues doesn’t mean that a collision occurs when the domain name is registered again. The domain name was external when its registration was not renewed, and it will continue to be external when it’s registered again; there’s no change in assumptions about the placement of the domain name in a name space.
2. A query that results in an NXDOMAIN response isn’t a name collision. The installed system that generated the query may have assumed that the domain name is in an internal name space, or it may have assumed that it’s in an external one. It’s not possible to tell directly from a query what assumptions were made, and therefore whether those assumptions would be at risk if the response were to change from NXDOMAIN to a resource record. This is why there’s a need for qualitative analysis (and, in particular, the name collision management framework that ICANN resolved to develop).

So it should be clear that periodic changes in registrants as well as evidence of NXDOMAIN activity should not be confused with actual name collision risks, which depend on analysis of the queries themselves. Rather, one must look on the other side of the ecosystem, at the installed systems that interact with the global DNS and the evolution of their assumptions about internal vs. external name spaces. The difference between established gTLDs and new gTLDs becomes obvious in light of the differences in “expectations of their usage and policies,” as illustrated by the three examples below:

• In February 2013, the CA/Browser Forum resolved that certificate authorities should no longer issue certificates bearing internal domain names. This was a direct consequence of the potential that those names might collide with the new gTLDs, as SSAC had noted in SAC057. There had been no previous need for SSAC or the CA/B Forum to sway certificate authorities away from issuing internal-name certificates on the basis that they might collide with established TLDs. Internal name spaces and the global DNS were already understood to be separate.
• In December 2013, ICANN issued a 20-page document advising IT professionals on how to mitigate name collision risks. This was also a response to the name collision issue for new gTLDs. There had been no previous need for ICANN to offer such advice about established TLDs, again because of the understanding that internal name spaces were safely separate. Indeed, had there been such a need, a statement along these lines surely could have been included by SSAC in SAC045, which provided initial guidance on the name collision issue in 2010. Such a statement would likely have elicited a more immediate response than it did, given that SSAC, in this hypothetical scenario, would have been drawing attention to both potential future and current dangers. Instead, SSAC focused on the impending risks of new gTLDs, and the later ICANN guidance was issued accordingly.
• In January 2014, the DBOUND mailing list was established within the IETF to discuss the challenges in managing policy information and other metadata about domain names, including, among other things, the public suffix list that specifies the administrative boundaries between domain name registries and managed domains. To quote from the mailing list charter: “Most of the existing mechanisms are managed semi-manually, and there are good reasons to suppose that the limits of such management are either about to be exceeded, or already have been”—again a direct consequence of the introduction of new gTLDs, or to quote further, the fact that “[t]he DNS root is expanding rapidly.”

As noted in Verisign’s preliminary comments, the combinational complexity of changes in certificate practices, installed system configuration, the public suffix list and other system components to support new gTLDs, dramatically increases the risk to users and system administrators for new gTLDs compared to established TLDs, where each of these controls have been worked out over time.

The potential risks are real, as Osterweil further observed, citing a well-known recipe for mounting a man-in-the-middle attack by exploiting name collisions and internal-name certificates that was offered by an audience member at a TLD Security Forum meeting in August 2013 (see the video transcript at 1:27:20).

If there’s any unevenness in the domain name landscape, then, it’s a result of the tectonic interruptions that are requiring users, system administrators, network operators, infrastructure providers and platform and application developers across the globe to update their installed systems to accommodate 1,400 or more new gTLDs. The parties who rely on the global DNS are the ones whose playing field is out of balance due to the largest operational change to the global DNS in its 30-year history.