Verisign posted preliminary public comments on the “Mitigating the Risk of DNS Namespace Collisions” Phase One Report released by ICANN earlier this month. JAS Global Advisors, authors of the report contracted by ICANN, have done solid work putting together a set of recommendations to address the name collisions problem, which is not an easy one, given the uncertainty for how installed systems actually interact with the global DNS. However, there is still much work to be done.

Below, I have outlined the four main observations from ICANN’s “Mitigating the Risk of DNS Namespace Collisions” Phase One Report discussed in Verisign’s public comment along with recommendations:

1. Name Collision Framework Not Yet Provided. ICANN resolved in October to “to develop a name collision occurrence management framework ... to assess both probability and severity of impact resulting from name collision occurrences.” This was intended to have resulted in specific mitigation measures per new gTLD and potentially per SLD. The Phase One Report doesn’t deliver the framework; but suggests a generic (and clever) mitigation measure, “controlled interruption,” to be applied to all new gTLDs (except for three that the JAS report recommends be blocked entirely). Presumably the framework will be included in Phase Two Report, now expected in June. But it would be premature for ICANN to act on the Phase One Report and implement its recommendations, before the actual framework that ICANN resolved to develop is available for public review.
2. “Controlled Interruption” Untested, May Not Be Effective. The “controlled interruption” technique for notifying users and system administrators that a change to the DNS is about to occur is unprecedented. The technique has never been deployed at the scale proposed, where the DNS responses to potentially hundreds of new gTLDs and hundreds of thousands of SLDs are changed at the same time from “NXDOMAIN” to a novel IP address. There is no operational experience to indicate whether users and system administrators will detect that a controlled interruption has occurred, nor how long it may take them, after the detection, to remediate their systems.Furthermore, there are at least two scenarios where it appears plausible that users and system administrators might not actually get notified that a change is forthcoming.

The second relates to the fact that certain service-discovery protocols that use the DNS are, by design, resilient to interruption. With such protocols, if a DNS response is changed to the controlled interruption IP address as suggested, rather than producing a user-visible error message, the application will go on and try another domain name. As one example, there is evidence that some installed systems running the WPAD protocol to discover a Web proxy may be regularly generating queries involving new gTLDs (this concern was raised by Andrew Simpson in a paper at the recent Name Collisions Workshop). Because the WPAD protocol is resilient, users and systems administrators won’t necessarily detect that an interruption has occurred, and therefore may not remediate, which means that the at-risk queries will continue after the interruption period.

3. Controlled Interruption May Break Systems that Are Not at Risk. The intent of controlled interruption is to notify users and system administrators that a change to the DNS is about to occur. However, the actual change that is about to occur is not that every possible SLD will be delegated or even that every SLD on a block list will necessarily be, but rather that some SLDs are going to be delegated. This could be a small number or a large number, but in general it won’t involve every possibility.

There is therefore a reasonable case to be made, at least for some new gTLDs and SLDs, that the controlled interruption should be done more selectively—for instance, only to a defined set of SLDs—in effect, an “SLD white list” that would be eligible to be delegated after the controlled interruption period, or to all SLDs except for an “SLD black list” that would not be eligible to be delegated.

4. Risk Management Requires Feedback. An essential element of any risk management process is a feedback mechanism that provides evidence of whether, in fact, the risk factors of concern have actually been mitigated. The Phase One Report does propose a feedback mechanism, but it’s only to confirm that the new gTLD operator has implemented the “controlled interruption” technique as recommended. It does not confirm that the technique, once implemented, has its intended effect.

If the controlled interruption technique is indeed effective, then the combination of probability and severity of impact should demonstrably decrease over the course of the interruption period as users and system administrators are notified and remediate their systems. It should be possible for a new gTLD operator, using similar techniques as developed for the framework, to measure risk both before and after the mitigation measure is applied, and therefore to understand how the risk has changed. This not only provides assurance that the intervention has been worthwhile, but also gives an indication of the residual risk that may still need to be mitigated (which, one hopes would ideally be close to zero). In addition, the feedback would provide valuable guidance for improving the mitigation measure for future new gTLDs, including guidance on how long the interruption period needs to be.

To submit your own comment on ICANN’s report, or to see Verisign’s comment, as well as comments from several other reviewers, visit the ICANN public comments forum. The full comment period closes this Monday, April 21.

To learn more about what name collisions are, why they occur, and why they matter, as well as how to assess name collisions risks and prepare for mitigations in your installed systems and networks, please join a complimentary webinar titled Name Collisions in the Domain Name System that I will be hosting along with USTelecom tomorrow, Thurs., April 17 at 1:00 pm EDT.