IAB Technical Comment on the Unique DNS Root

Internet Architecture Board

Technical Comment on the Unique DNS Root

(Received September 27, 1999)



The Internet, to remain a global network, technically requires the existence of a globally unique public name space. The DNS name space is a hierarchical name space derived from a single, globally unique root. This is inherent in the design of the DNS system. Therefore it is not technically meaningful for there to be more than one root in the public DNS system. That one root must be supported by a small number of coordinated root servers, and administered by a unique naming authority.

Put simply, allowing multiple public DNS roots would raise a very strong possibility that users of different ISPs who click on the same link on a web page could end up at different destinations, against the will of the web page designers.

This does not preclude private networks from operating their own private name spaces, but if they wish to make use of names uniquely defined for the global Internet, they have to fetch that information from the global DNS naming hierarchy, and in particular from the coordinated root servers of the global DNS naming hierarchy.


There are two reasons for a single DNS root:

1. For any communications between two parties to be effective there are two essential preconditions: The existence of a common symbol set, and the existence of a common semantic interpretation of these symbols. Failure of the first condition implies a failure to communicate at all, and failure of the second implies that the meaning of the communication is lost.

In the case of a public communications system this condition of a common symbol set with a common semantic interpretation must be further strengthened to that of a unique symbol set with a unique semantic interpretation. This condition of uniqueness allows any party to initiate a communication that can be received and understood by any other party. Such a condition rules out the ability to define a symbol within some bounded context. In such a case, once the communication moves out of the context of interpretation in which it was defined, the meaning of the symbol becomes lost.

Within public digital communications networks such as the Internet this requirement for a uniquely defined symbol set with a uniquely defined meaning exists at many levels, commencing with the binary encoding scheme, extending to packet headers and payload formats and the protocol that an application uses to interact. In each case a variation of the symbol set or a difference of interpretation of the symbols being used within the interaction causes a protocol failure, and the communication fails. The property of uniqueness allows a symbol to be used unambiguously in any context, allowing the symbol to be passed on, referred to, and reused, while still preserving the meaning of the original use.

The DNS fulfils an essential role within the Internet protocol environment, allowing network locations to be referred to using a label other than a protocol address. As with any other such symbol set, DNS names are designed to be globally unique, that is, for any one DNS name at any one time there must be a single set of DNS records uniquely describing protocol addresses, network resources and services associated with that DNS name. All of the applications deployed on the Internet which use DNS assume this, and Internet users expect such behavior from DNS names. Names are then constant symbols, whose interpretation does not specifically require knowledge of the context of any individual party. A DNS name can be passed from one party to another without altering the semantic intent of the name.

Since the DNS is hierarchically structured into domains, the uniqueness requirement for DNS names in their entirety implies that each of the names (sub-domains) defined within a domain has a unique meaning (i.e. set of DNS records) within that domain. This is as true for the root domain as for any other DNS domain. The requirement for uniqueness within a domain further implies that there be some mechanism to prevent name conflicts within a domain. In DNS this is accomplished by assigning a single owner or maintainer to every domain, including the root domain, who is responsible for ensuring that each sub-domain of that domain has the proper records associated with it. This is a technical requirement, not a policy choice.

2. Both the design and implementations of the DNS protocol are heavily based on the assumption that there is a single owner or maintainer for every domain, and that any set of resources records associated with a domain is modified in a single-copy serializable fashion. That is, even assuming that a single domain could somehow be "shared" by uncooperating parties, there is no means within the DNS protocol by which a user or client could discover, and choose between, conflicting definitions of a DNS name made by different parties. The client will simply return the first set of resource records that it finds that matches the requested domain, and assume that these are valid. This protocol is embedded in the operating software of hundreds of millions of computer systems, and is not easily updated to support a shared domain scenario. Morever, even supposing that some other means of resolving conflicting definitions could be provided in the future, it would have to be based on objective rules established in advance. (For example, zone A.B could declare that naming authority Y had been delegated all subdomains of A.B with an odd number of characters, and that naming authority Z had been delegated authority to define subdomains of A.B with an even number of characters.) Thus, a single set of rules would have to be agreed to prevent Y and Z from making conflicting assignments, and with this train of actions a single unique space has been created in any case. Of course this would not allow multiple non-cooperating authorities to assign arbitrary sub-domains within a single domain; it seems that a degree of cooperation and agreed technical rules are required in order to guarantee the uniqueness of names. In the DNS, these rules are established independently for each part of the naming hierarchy, and the root domain is no exception. Thus, there must be a generally agreed single set of rules for the root.


There is one specific technical respect in which the root zone is different from all other DNS zones: the addresses of the name servers for the root zone come primarily from out-of-band information (named.root files from the ISC BIND distribution, your ISP, whatever) rather than via the NS RR delegation chain. NS RRs for the root zone, while present, are almost irrelevant. In effect, every full-service resolver in the world "delegates" the root of the public tree to the public root server(s) of its choice.

As a direct consequence, any change to the list of IP addresses that specify the public root zone is significantly more difficult than changing any other aspect of the DNS delegation chain. Thus, stability of the system calls for extremely conservative and cautious management of the public root zone (low churn rate, relatively tight update coupling between the servers, etc), because it's very difficult to route around a misbehaving root server.


The DNS type of unique naming and name-mapping system may not be ideal for a number of purposes for which it was never designed, such a locating information when the user doesn't precisely know the correct names. As the Internet continues to expand, we would expect directory systems to evolve which can assist the user in dealing with vague or ambiguous references. To preserve the many important features of the DNS and its multiple record types --including the Internet's equivalent of number portability-- we would expect the result of directory lookups and identification of the correct names for a particular purpose to be unique DNS names that are then resolved normally, rather than having directory systems 'replace' the DNS. There is no getting away from the unique root of the public DNS.

Brian Carpenter
IAB Chair