We often imagine the Domain Name System (DNS) as a rooted tree. In fact, as depicted in Figure 1, the so-called DNS name space is exactly that.
This basic graph structure is reasonably easy to understand for newcomers. In the nomenclature of graph theory, there is one directed path from the root along a series of edges to any other vector (or node), where vectors represent the labels in a DNS name.
Figure 1 – Sample DNS name space hierarchy depicting a path to the BITS lab website at the University of Illinois at Chicago, the group where the author is currently conducting his research as a PhD student.
With this image of the name space in mind, try to imagine what the graph might look like when we make the authoritative name servers the vertices for the name space. This is a reasonable request since they provide the name data along the name space path.
Each name server in a parent name server resource record set (NS RRset) points to a child vertex along the directed path. Each vertex is either another NS RRset or a terminal name. Since it isn’t strictly important for our purposes, we’ll conveniently ignore that in the DNS, a vertex could be both, depending on context.
If there were only a single name server for each vertex that has one, the graph would resemble the idealized name space graph and thus be easy to visualize. However, as we know, practically all serious deployments use multiple name servers in the NS RRset and this complicates the graph enormously.
In fact, I contend that it is likely impossible to construct a definitive version of the DNS graph at any point in time this way. The challenge stems from the phenomenon of DNS inconsistency, particularly in real-world NS RRset deployments. By way of example and measurement, we’ll see if, by the end of this post, you agree with this supposition.
Let’s now consider a simply construed, but realistic example of DNS inconsistency:
Parent NS RRset *p* for example.edu.
example 1D IN NS ns1.example.edu.
example 1D IN NS ns2.example.edu.
Child NS RRset *c* for example.edu.
example 1D IN NS ns1.example.edu.
example 1D IN NS ns2.example.edu.
example 1D IN NS ns3.example.edu.
The disagreement over which name servers are authoritative for a zone between the parent and child name servers is commonly found in the wild.
The scenario above demonstrates one of the most common forms of inconsistency, where the child servers list additional authoritative name servers than is listed at the parent. This is also probably the most benign form. Not all three child name servers may be selected in equal proportion, as resolvers traverse the name-space path or may be suboptimal, however, this should work fine.
Now consider a similar configuration where the parent servers list a name server that the children do not:
Parent NS RRset *P* for example.edu.
example 1D IN NS ns1.example.edu.
example 1D IN NS ns2.example.edu.
example 1D IN NS ns3.example.edu.
Child NS RRset *C* for example.edu.
example 1D IN NS ns1.example.edu.
example 1D IN NS ns2.example.edu.
In this revised scenario, we have to ask what happens when resolvers end up trying to query ns3.example.edu, as they are sure to do from time to time?
Maybe there is a valid DNS server there, but it just isn’t marked as part of the child NS RRset? Maybe ns3 points to an unavailable or undefined system and queries that choose it will incur a timeout? Perhaps, worst of all, there is a name server there that answers, but is providing outdated or incorrect information?
By this time you should begin to get a sense of the problems that can arise from name server inconsistency. Depending on the name server selected, a resolver may end up in a wildly divergent place than it would have if traversing another path through the name space.
This leads us to a number of questions that form the basis of some of my research work.
- How prevalent are these sorts of problems?
- What are the root causes of DNS inconsistency seen on the Internet? How does inconsistency affect the performance and security of the Internet?
- What can we do or how could we change the DNS to minimize inconsistency?
DNS inconsistency is one of my ongoing research problems so I’ll offer just a glimpse of what we see for NS RRset inconsistency in the part of the .edu name space that we have measured.
Inconsistencies in the .edu name space
Earlier this year, I performed a number of active measurements on the .edu name space, focusing specifically on the second-level domains and the name server discrepancies between the parent and child name server sets. The .edu zone is small and diverse enough that we should be able to make some reasonable conclusions about what we might expect to find throughout other parts of the DNS.
Figure 2 summarizes the approximate amount of NS RRset consistency between child and name servers for .edu.
Figure 2 – Summary of NS RRset consistency observed between parent and child name servers for the .edu name space.
Roughly speaking, the frequency with which the parent lists more name servers than the child arises almost as often as when the child lists more name servers than the parent. In a smaller number of cases, we find they list the same number of name servers, but the two sets are not the same.
Overall, approximately one-quarter of all names in the .edu exhibit some form of NS RRset inconsistency.
Addressing inconsistencies is difficult
We see a significant amount of NS RRset inconsistency in the wild. While some forms of inconsistency can be benign or pose few problems for actual DNS operation, most types of inconsistency pose serious DNS performance penalties or domain name hijacking risks.
We find that inconsistency increases the deeper we look into the name space. This presents a unique challenge, as along with name server delegation comes increasingly diverse administrative responsibility. Addressing inconsistency problems is therefore unlikely to occur in just a few centralized locations or by changes made by a small number of operators.
Parent and child name server set provisioning is typically a manual, loosely-coupled process. When we don’t automatically synchronize parent and child lists, we are at the mercy of human behaviour to ensure the two are synchronized. Over time, natural decay for any widely distributed system can set in.
Until or unless we find ways to make the DNS more naturally consistent, operational practices must improve for the DNS data to achieve a higher rate of consistency.
John Kristoff is a network architect in the Information Services division and adjunct faculty member in the College of Computing and Digital Media at DePaul University. He is also enrolled as a PhD student in Computer Science at the University of Illinois Chicago.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.