The topic of name collisions has received considerable attention in the DNS and Internet communities over the past several months. A name collision occurs when an attempt to resolve a name that is used in a private name space (e.g., a non-delegated Top Level Domain, or a short, unqualified name) results in a DNS query to the public DNS and there is matching name in the public DNS.
Name collision occurrences are not new and have been historically observed and reported as queries containing non-delegated TLDs at the root level of the DNS [PDF, 507 KB]. Such occurrences have received renewed attention because many applied-for new TLD strings are identical to name space labels used in private networks.
ICANN and others have conducted studies to assess the potential impact on Internet users [1 (PDF, 3.34 MB), 2]. From these studies, we are able to observe symptoms that are indicative of misdirected name queries, identify the approximate origins and causes of these queries, and suggest remedies (mitigations).
Treat the cause, not the symptom, of name collisions
Conventional wisdom, be it applied to medicine or Internet security, is to treat the cause, not the symptom. Blocking or sinkholing domains or URLs to prevent malicious software on a device from communicating with a botnet command and control center is an example of treating a symptom [3 (PDF, 386 KB), 4]. Such countermeasures provide relief and reduce risk, but the infection is still present, and remains a threat. Identifying infected devices, removing the malware and in parallel dismantling the botnet, is an example of treating the cause [5], which is hopefully – and preferably – permanent.
With name collision, blocking or delaying delegation of an applied-for TLD treats a symptom but also discounts an important consideration: name collisions are unintended TLD queries to the root level of the public DNS. They are instances where name queries “leak” from their intended private namespace.
The use of private namespaces or short, unqualified names are prevalent causes of name collisions. These uses have many origins including protocol choice, user convenience, and application design or implementation assumptions. Configuration confusion, choice or error are also commonly cited or observed causes of unintended queries to the root. These causes have persisted for a number of reasons. Irrespective of the reason, many organizations may want to mitigate name query leaks from their intended private namespaces.
ICANN is taking measures to relieve symptoms of name collision. These measures are published in a New gTLD Collision Occurrence Management Plan and are intended to provide time for organizations to:
- Investigate their internal name spaces to identify whether they are submitting queries including non-delegated TLDs to the public DNS root
- Assess whether these queries pose an unacceptable risk to their organizations, and
- Determine how they will mitigate risk.
The framework measures ICANN and new TLD applicants will implement are diagnostic and containment measures, but they do not treat the underlying cause. Treating the cause is a decision for and responsibility of organizations that use private and/or short unqualified names. This fact, too, is often neglected in name collision discussions: only organizations that are misdirecting queries to the public DNS can correctly determine whether they are at risk and only they can implement measures to mitigate risk to their satisfaction.
ICANN has consulted with subject matter experts to prepare a report on mitigating causes associated with short unqualified name use. The principal finding and recommendation in the report, Guide to Name Collision Identification and Mitigation for IT Professionals [PDF, 228 KB], is
Where the resolution of short unqualified names is the cause, then the resolution of fully qualified domains via the public DNS is an appropriate and recommended cure.
The report describes the problems that organizations may encounter when internal names leak to the global DNS and recommends remedies that are practical and achievable for many organizations. It considers private name spaces that branch off the DNS, private namespaces that use their own private TLDs, and private namespaces that are created by the use of search lists.
The report recommends that every organization that is not already using FQDNs from the public DNS should consider the following strategy. Briefly, the report recommends that you:
- Monitor name services, compile a list of private TLDs or short unqualified names you use internally, and compare the list you create against the list of new TLD strings.
- Formulate a plan to mitigate causes of leakage; for example, you may need to change the root of your private namespace to use a name you have registered in the global DNS, or change affected systems over to use FQDNs.
- Prepare your users for the impending change in name usage by notifying them in advance or providing training.
- Implement your mitigation plan.
- Continue to monitor old private name usage as well as new FQDN usage at name servers and along your network perimeter, and use these data to mitigate any causes you may discover once you’ve begun mitigating leaks.
Mitigations of this kind are necessary but not new to IT administrators. Just as it is necessary to identify infected PCs in an edge network and remove malware, it will also be necessary to identify and eliminate the causes of internal name vulnerabilities in edge networks. It is also important to recognize that organizations already using FQDNs from the public DNS in their network won’t have to consider these measures. These organizations will see no difference to their own use of DNS names irrespective of which or how many new TLDs are delegated.
While other interim or makeshift solutions may exist, migration to using FQDNs has lasting value – once you’ve done this, you are good to go for all new TLD delegations.
Dave Piscitello, VP Security and ICT Coordination, ICANN