server.example.com. So how do search lists actually work? Or perhaps maybe we should first ask: how were search lists intended to work?

Consulting the RFCs

The base specification of the DNS, RFC1034, assumed that any name requiring resolution was either a complete (or “absolute”) domain name, or an incomplete (or “relative”) domain name. Absolute domain names were names that would be passed as a query to the DNS without further modification, while relative domain names required the appending of a locally defined name to form an absolute name. RFC1034 proposed that name forms that ended with a “.” were to be interpreted as absolute names, while other names were relative names.

This approach has the downside of potentially directing many queries to the servers who are authoritative for the root of the DNS, and this specification in RFC1034 was subsequently modified in RFC1123 such that the local name resolution system should require that a name has three or more individual labels (“two or more interior dots in a generated domain name”) before submitting the query to the DNS for resolution.

But even this approach generates excessive query traffic at the root of the DNS. RFC1536 noted the example of a local name of usc.edu within a local domain search space of foo.bar.com. Because the original name is missing that essential trailing dot it is being interpreted as a relative domain name, and the search list of foo.bar.com is appended, resulting in a query for usc.edu.foo.bar.com, then usc.edu.bar.com, then finally usc.edu. RFC1536 (an informational RFC) proposed a modification to the original absolute/relative name distinction, that a name that already contains multiple labels (“contains any dots” to quote RFC1536) should first be tried as a fully qualified domain name, and if that fails then the local search list can be applied to the name. In other words the reverse of the original search list behaviour. If the name is a single label, then the search list can be applied immediately. RFC3397 attempted to clarify this application of search lists to local names, taking the description in RFC1536 and re-casting them in the context of a Proposed Standard, without changing the substance of the proposed modifications.

So how have implementations interpreted these specifications?

Testing Search Lists and Dotless Names

How do various name resolver libraries implement the application of search lists in their local name resolution libraries? Will “dotless” domain names in the DNS be masked out by local domain name search lists? I have performed some basic tests on a number of popular operating systems, using their default configuration settings for name resolution.

The tests were set up using a simple application that called the local system’s name resolution subroutine library. The local system’s DNS query traffic was captured using tcpdump to allow the DNS queries to be recorded. There are four types of behaviour that have been observed in this experiment:

• never – the search list is not applied, and the original name is queried in the DNS
• always – the search list is always applied and the synthesised names are queried in the DNS, but the original name is never queried in the DNS
• pre – the search list is applied to the original name in DNS queries, and if all permutations of the application of the search list generate a NXDOMAIN response then the original name is queried in the DNS
• post – the original name is queried in the DNS, and if this generates an NXDOMAIN response then the search list is applied to the original name in DNS queries.

The results of this survey of the name resolution behaviour of the more popular systems are shown in the following table:

The mix of behaviours seen here shows some evolution in thinking about the “appropriate” use of search names across the various operating system vendors.

In the case of “absolute” domain names (ending with a dot), all systems interpret the name as a fully qualified name and do not apply any local search list.

In the case of so-called “relative names”, the behaviours are variable. For single label domains we see many systems use the RFC1034 specification, and assume that the original name is a relative name and requires the use of the local search list in all cases. The FreeBSD and Ubuntu systems use a variation to his approach, and if the application of the search list yields no such domain (NXDOMAIN) responses in all cases, then a query for the dotless name is then passed into the DNS.

For multi-label domains some systems implement the procedures described in RFC1536, and treat the multi-label name firstly as an absolute name, and if that produces a NXDOMAIN response, then the local search list is applied. However later versions of Windows (Vista, 7 and 8) and the current MAC OSX systems treat the multi-label name as an absolute name and will not apply the local search list, even if the queries based on the application of the search list all generate NXDOMAIN responses.

The FreeBSD and Ubuntu behaviours also appear anomalous to me, in so far as the ordering of the search list and the base name queries is reversed, depending on whether the base name was dotless or not, but perhaps that a criticism of the state of the standard specification where the combination of RFC1034 and RFC1536 can lead an implementor to this outcome as being consistent with the specifications contained in these two documents.

So if you want to use a dotless label as a domain name, would it work? The basic answer is “probably not”, unless of course you somehow coerced all forms of use of the name to include the trailing dot to re-cast the name as an absolute name. However the use of the trailing dot is largely fallen into disuse, and in its relative name form the dotless name looks a lot less viable. On Mac and Windows systems the local system would always apply the local search list to the name, and then attempt to resolve the consequent multi-label name. In such contexts the dotless name is never queried. For FreeBSD and Ubuntu systems (and presumably Fedora systems and other Linux variants) the local system will first apply the local DNS search list to the name, and only if these names all generate NXDOMAIN responses would the local system query for the dotless name.

Dotless Name Collision?

Into this somewhat convoluted picture of name resolution comes the concept of dotless name collision. Would the delegation of a new gTLD name somehow alter the name resolution behaviour of clients if the same name was being used in some purely local context?

If the local use is accompanied by a locally scoped name resolver, then local clients will still resolve names in this name space within the context of the local resolver, and nothing has changed for them. If local clients were relocated into a name resolution environment outside the scope of the local name resolver, and still attempted to resolve names using the local name space, then there are some potential issues. Whereas previously such displaced use of the name would result in NXDOMAIN responses, there is the potential for the name to be unexpectedly resolved in the context of the gTLD. Now it must be stressed here that the problem is not the delegation of the gTLD per se that has caused this unexpected outcome, but the movement of a client system outside of the context of a locally scoped name that has been locally configured as a pseudo-TLD, while still retaining some vestige of the name’s definition within the client’s configuration settings.

The instance of single name queries in the queries presented to the DNS root servers is a testament to the observation that such locally scoped use of names, and the associated leakage of name scope, does occur, but the question is whether delegation of this name as a new gTLD would alter or otherwise compromise client behaviour in any fashion beyond what would be expected in an undelegated scenario. There is little to suggest that this scope leakage of private use of a name is a substantial issue, and there is nothing in the nature of the way local search lists are applied that the instantiation of a name as a new gTLD would occlude the locally scoped use of the same name.

So global definition of a name would not, in general, occlude the visibility and use of the same name in locally scoped name resolution contexts.

Perhaps the only substantive issue here is the reverse form of name occlusion, where if a name that is commonly used in private context is delegated in the DNS root as a new gTLD, then none of the clients in these private contexts will have any direct visibility of the global name.

The piecemeal fragmentation of the name space by use of these locally scoped pseudo-gTLDs was never the best of ideas in an identifier realm such as the DNS that has no implicit understanding of name scoping or name realms. Applications, users and servers all implicitly assume that DNS names are globally scoped identifiers, and when local practices break this assumption then in some sense the consequences in terms of name use conflict are self-inflicted. As far as I can tell, the basic intention of local name search lists was not to augment a local name realm with privately used pseudo-TLDs, but to allow the local users to use a common global name implicitly, so that local use of simple, single label name forms can be transformed into fully qualified domain names. Within my local scope I can refer to a resource or service with a single label, and the local search list should transform this single dotless label into a fully qualified domain name that is then resolved in the context of the DNS itself.

Now if only we could agree on a consistent interpretation of the use of name search lists that implement that form of simple naming convenience!

Further Reading:

Internet Architecture Board: “Dotless Domains Considered Harmful,” July 2013.
New gTLD Program Committee of the ICANN Board, “Approved Resolution on Dotless Domains”, September 2013.
ICANN Security and Stability Advisory Committee, “SSAC Report on Dotless Domains”, February 2012.
J. Levine, P. Hoffman, “Top Level Domains that Are Already Dotless,” Internet Draft, October 2013.