An independent report commissioned by ICANN, Mitigating the Risk of DNS Namespace Collisions, has offered a set of concrete recommendations on how to mitigate potential risks of domain name collisions

A name collision occurs when an attempt to resolve a name used in a private name space results in a query to the public Domain Name System (DNS).

“This report takes an in-depth look at the collision issue and the potential risks and impacts, and gives us some very clear advice aimed at how to help system operators detect and mitigate those risks,” said Akram Atallah, President of ICANN’s Global Domains Division. “The next step is to seek input from our community on the report’s findings.”

The report stressed that name collisions are nothing new and that any issues that arise from expansion of the Top-Level Domains (TLDs) under ICANN’s New gTLD program would resemble those that occur in other parts of the DNS. But the report noted that expanding the number of TLDs will not fundamentally or significantly increase the risks of name collisions.

Specifically, the study outlines a set of recommendations on how ICANN and the TLD operators should handle the issue of name collisions in the expanding TLD space:

ICANN should require new TLD registries to implement and publish a 120-day controlled interruption zone monitored by ICANN immediately upon delegation in the root zone.

After the 120-day period, there shall be no further collision-related restrictions on the TLD.

ICANN should have emergency response processes to analyze and act upon reported problems that present “clear and present danger to human life”.

ICANN and others in the community should continue to collect and analyze data relating to the root servers and to the controlled interruption.

The Top-Level Domains .corp, .home and .mail should be permanently reserved.

The report is posted for public comment until April 21, 2014.

Here is some of the more interesting finding and recommendations from the report:

We do not find that the addition of new Top Level Domains (TLDs) fundamentally or significantly increases or changes the risks associated with DNS namespace collisions. The modalities, risks, and etiologies of the inevitable DNS namespace collisions in new TLD namespaces will resemble the collisions that already occur routinely in the other parts of the DNS. The addition of multiple new TLDs over the past decade (generic and country code) has not suggested that new failure modalities might exist; rather, the indication is that the failure modalities are similar in all parts of the DNS namespace.

That said, DNS namespace collisions are a complex and pervasive occurrence that manifests throughout the global Internet DNS namespace. Collisions in all TLDs and at all levels within the global Internet DNS namespace have the ability to expose potentially serious security and availability problems and deserve serious attention. While current efforts to expand the global DNS namespace have collision-related implications, the collision problem is bigger than new TLDs and must be viewed in this context.

In summary, our recommendations describe a comprehensive approach to reducing current and future DNS namespace collisions, alerting operators of potential DNS namespace related issues, and providing emergency response capabilities in the event that critical (e.g., life safety) systems are adversely impacted.

DNS namespace collisions exist outside of, and independently from, the current efforts to expand the DNS namespace. They have almost certainly existed since the

Given that the Internet has demonstrated a need for RFC 1918-like DNS namespaces, we recommend that .corp and .home be permanently reserved for internal use and receive RFC 1918-like protection/treatment.

Like .corp and .home, the TLD .mail also exhibits prevalent, widespread use at a level materially greater than all other applied-for TLDs. Our research found that .mail has been hardcoded into a number of installations, provided in a number of example configuration scripts/defaults, and has a large global “installed base” that is likely to have significant inertia comparable to .corp and .home. As such, we believe .mail’s prevalent internal use is also likely irreversible and recommend reservation similar to .corp and .home.

RECOMMENDATION 1: The TLDs .corp, .home, and .mail be permanently for internal use.

RECOMMENDATION 2: ICANN continue efforts to make technical information available in fora frequented by system operators (e.g., network operations groups, system administration-related conferences, etc.) regarding the introduction of new gTLDs and the issues surrounding DNS namespace collisions.

RECOMMENDATION 3: Emergency response options are limited to situations where there is a reasonable belief that the DNS namespace collision presents a clear and present danger to human life.

RECOMMENDATION 4: Root-level de-delegation of a production TLD is not considered as an emergency response mechanism under any circumstances.

RECOMMENDATION 5: ICANN leverage the EBERO mechanisms and functionality to respond to DNS namespace-related issues. ICANN must have the following capabilities on a 24x7x365, emergency basis:

1). Analyze a specific report/incident to confirm a reasonable clear and present danger to human life;

2). Direct the registry on an emergency basis to alter, revert, or suspend the problematic registrations as required by the specific situation;

3). Ensure that the registry complies in a timely manner; and

4). Evaluate and monitor the specific situation for additional required actions.

Furthermore, we recommend that ICANN develop policies and procedures for emergency transition to an EBERO provider and/or emergency root-level de-delegation in the event the registry is unable and/or unwilling to comply. We recommend ICANN maintain this capability indefinitely.

RECOMMENDATION 6: ICANN require new TLD registries to publish the controlled interruption zone immediately upon delegation in the root zone. After the 120-day period, there shall be no further collision-related restrictions on the registry.

RECOMMENDATION 7: ICANN require registries that have elected the “alternative path to delegation,” rather than a wildcard, instead publish appropriate A and SRV resource records for the labels in the ICANN 2LD Block List

RECOMMENDATION 8: ICANN relieve the prohibition on wildcard records during the controlled interruption period.

RECOMMENDATION 9: ICANN monitor the implementation of controlled interruption by each registry to ensure proper implementation and compliance.

RECOMMENDATION 10: ICANN, DNS-OARC, and the root operators explore a medium-latency, aggregated summary feed describing queries reaching the DNS root.

RECOMMENDATION 11: ICANN, DNS-OARC, and the root operators explore establishment of a single, authoritative, and publicly available archive for historical data related to the root.

You can read the entire study here.

You can comment up to April 21st