Internet Architecture Board


IAB Statement: Dotless Domains Considered Harmful

Home»Documents»IAB Correspondence, Reports, and Selected Documents»2013»IAB Statement: Dotless Domains Considered Harmful

Executive Summary:

It has come to the attention of the IAB that there are proposals for so-called “dotless” domains in the root zone, and that some existing top-level domains (TLDs) are already operating in such a mode. TLD operators of dotless domains are intending that single label names — those containing no dots — resolve to the TLD itself, rather than be resolved locally, within the context of the local site at which the user resides.

Unfortunately, dotless domains will not work as intended by TLD operators in the vast majority of cases. As recommended by IETF standards track RFCs, existing deployed systems apply a search list to single-label names prior to attempting to resolve them. As a result, the resolution of dotless domains depends on local configuration such as the search list. For example, in a location where “” is included within the search list, the URL http://printer1/ will generate a query for “”, whereas in a location where “” is in the search list, it will generate a query for “”.

This behavior was developed in the DNS precisely because most users entering single-label names want them to be resolved in a local context, and they do not expect a single name to refer to a TLD. The behavior is specified within a succession of standards track documents developed over several decades, and is now implemented by hundreds of millions of Internet hosts. This standard approach enables single-label names to be conveniently used as shortcuts to hosts within a local administration, while also shielding the root zone from a potentially excessive number of queries for single-label names. Since the configuration of the search list has security implications, it is under the control of local host and network administrators, and completely outside the control of TLD operators.

Since dotless domains will not behave consistently across various locations (and applications and platforms that may have different search list configuration mechanisms), they have the potential to confuse users and erode the stability of the global DNS. By attempting to change expected behavior, dotless domains introduce potential security vulnerabilities. These include causing traffic intended for local services to be directed onto the global Internet (and vice-versa), which can enable a number of attacks, including theft of credentials and cookies, cross-site scripting attacks, etc. As a result, the deployment of dotless domains has the potential to cause significant harm to the security of the Internet.

The IAB therefore feels compelled to state the following:

  1. The IAB strongly recommends against considering, implementing, or deploying dotless domains.
  2. The IAB believes that dotless domains are inherently harmful to Internet security.
  3. Applications and platforms that apply a suffix search list to a single-label name are in conformance with IETF standards track RFCs. Furthermore, applications and platforms that do not query DNS for a TLD are in conformance with IETF standards track recommendations intended to minimize security vulnerabilities and reduce load on the root servers.

Discussion of standards conformance:

Since the advent of the DNS, Internet naming systems have always relied on the presence of dots in names to distinguish between names that are intended to be interpreted locally, and names that are intended to be looked up on the Internet. Dotless domains lead to ambiguities in their resolution, and therefore unintended and unexpected results when used by proper implementations of IETF standards. The IAB believes that SSAC report SAC053 [SAC053] is a reasonable summary of the technical problems that arise from the implementation of dotless domains. SAC053 does not, however, discuss the standards compliance aspect. Since the IAB believes that the security and stability of the root zone are critical in maintaining the continued viability and success of the Internet, the IAB wishes to comment further regarding compliance with applicable relevant standards that are authoritative and published by the relevant standards body, i.e., standards-track IETF RFCs.

The use of a suffix search list is part of the base DNS specification. RFC 1034 [RFC1034] (dated November 1987) section 3.1 for example states:

   Relative names are either taken relative to a well known origin, or to a
   list of domains used as a search list.  Relative names appear mostly at
   the user interface, where their interpretation varies from
   implementation to implementation, and in master files, where they are
   relative to a single origin domain name.  The most common interpretation
   uses the root "." as either the single origin or as one of the members
   of the search list, so a multi-label relative name is often one where
   the trailing dot has been omitted to save typing.

Configuration of the search list is specified in RFC 3397 [RFC3397] and RFC 3646 [RFC3646], both of which are Standards Track RFCs.

RFC 1123 [RFC1123] section bullet (2) then gives requirements for all Internet hosts relating to search lists. This document, like the DNS specification itself, is a “full” Standard (STD 3). It states:

   There is danger that a search-list mechanism will
   generate excessive queries to the root servers while
   testing whether user input is a complete domain name,
   lacking a final period to mark it as complete.  A
   search-list mechanism MUST have one of, and SHOULD have
   both of, the following two provisions to prevent this:

   (a)  The local resolver/name server can implement
        caching  of negative responses (see Section

   (b)  The search list expander can require two or more
        interior dots in a generated domain name before it
        tries using the name in a query to non-local
        domain servers, such as the root.

The use of SHOULD for (b) is a recommendation against doing DNS queries for dotless domains. RFC 2119 [RFC2119] explains the meaning of SHOULD as follows:

  This word, or the adjective "RECOMMENDED", mean that there
  may exist valid reasons in particular circumstances to ignore a
  particular item, but the full implications must be understood and
  carefully weighed before choosing a different course.

Because of the ubiquitous nature of the DNS and the inability to predict which applications or hosts or implementations will resolve a dotless domain, it is impossible to limit their risks.

RFC 1536 [RFC1536] (dated October 1993) section 6 states:

   In other words, Use searchlists only when explicitly specified.
   No implicit searchlists should be used. A name that contains
   any dots should first be tried as a FQDN and if that fails, with
   the local domain name (or searchlist if specified) appended. A
   name containing no dots can be appended with the searchlist right
   away, but once again, no implicit searchlists should be used.

The rule for a “name containing no dots” is thus distinct from the rule for a “name that contains any dots”. Although RFC 1536 itself is Informational (and this has led some to mistakenly assume the rule is unimportant), the same guidance was then incorporated into and repeated in multiple Standards Track RFCs.

For example, standards Track RFC 3397 (dated November 2002), section 4 states:

 [RFC1536] section 6 also addresses this vulnerability, and recommends that resolvers:

 [1]   Use searchlists only when explicitly specified; no implicit
       searchlists should be used.

 [2]   Resolve a name that contains any dots by first trying it as an
       FQDN and if that fails, with the local domain name (or
       searchlist if specified) appended.

 [3]   Resolve a name containing no dots by appending with the
       searchlist right away, but once again, no implicit searchlists
       should be used.

  In order to minimize potential vulnerabilities it is recommended

  [a]   Hosts implementing the domain search option SHOULD also   
        implement the searchlist recommendations of [RFC1536], section

Similarly, Standards Track RFC 3646 (dated December 2003), section 6 again repeats the same recommendations.

Hence the RFC 1536 section 6 recommendations are a SHOULD in Standards Track RFCs, and following this recommendation is important to minimize potential security vulnerabilities.

The IAB is aware that there are top-level domains on the Internet that offer services at that top-level domain. While dotless domains may work with some implementation configurations in some locations, hundreds of millions of deployed systems will not behave as expected by TLD operators. Since TLD operators lack the administrative authority to configure implementations to behave as they would like, the implementation of dotless domains will inevitably result in user confusion as well as security vulnerabilities, eroding the stability and security of the global DNS. In general, conformance to IETF recommendations is even more important for the root zone than for any other zone. This is why, in RFC 6912 [RFC6912] (section 2.1), the IAB recommended more restrictive rules the closer to the root one was.

In summary, the IAB believes that the current IETF recommendations against the use of dotless domains are important to the continued viability and success of the Internet, and strongly recommends that the Internet community strictly adhere to them.


[SAC053] ICANN Security and Stability Advisory Committee, “SSAC Report on Dotless Domains”, SAC053. 23 February 2012. Retrieved from SAC053.

[RFC1034] Mockapetris, P., “Domain names – concepts and facilities“, STD 13, RFC 1034, November 1987.

[RFC1123] Braden, R., ed., “Requirements for Internet Hosts — Application and Support”, STD 3, RFC 1123, October 1989.

[RFC1536] Kumar, A., J. Postel, C. Neuman, P. Danzig, S. Miller, “Common DNS Implementation Errors and Suggested Fixes”, RFC 1536, October 1993.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC3397] Aboba, B. and S. Cheshire, “Dynamic Host Configuration Protocol (DHCP) Domain Search Option”, RFC 3397, November 2002.

[RFC3646] Droms, R, ed., “DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, RFC 3646, December 2003.

[RFC6912] Sullivan, A., Thaler, D., Klensin, J. and O. Kolkman, “Principles for Unicode Code Point Inclusion in Labels in the DNS”, RFC 6912, April 2013.