Internet Performance Delivered right to your inbox

Domain Name System (DNS) Delegation – The Zone Authority Chain

DNS Delegation

In this blog series we recently covered the core of DNS as well as major components of a single zone and zonefile. However the DNS is actually a series of delegations: the root . zone to the .com zone to the zone. How do those zones link together? This is done by that process mentioned earlier, delegation, in which one zone points the authority to the next in the chain. The process for looks like this using my own computer through Google DNS:

Google initially knows the names of the root nameservers because they are hard-coded into the hints file. Otherwise, how do you know where to start? The root zone looks at the request for and notices that it is in the com namespace. There is a label for com in the root zone, with 13 nameservers as NS records. The nameserver records found in the zone performing the delegation (root in this case) are known as the parent nameservers of the delegation. The inclusion of these nameservers at this spot indicates the answer to this query is not on the current nameserver or zone, and the resolver should try the ones provided.

This produces a zone cut to a new zone within the new delegated zone. At the location of those 13 new nameservers, there is a zone file for the domain of com, with a Start of Authority (SOA) record so indicating. Along with the SOA, there are an additional 13 nameservers in the apex of the com zone signaling that you are in the right place. These are known as the child nameservers of the delegation. The recursive follows this process, again and again, until it gets to the authoritative for the DNS name in question and “voila!” gets the answer.

For this example, the domain name is delegated to a nameserver that is a different domain entirely, but sometimes domain operators will choose to have the domain delegated to a nameserver within the zone itself. This is known as being in bailiwick and would look like being delegated to a nameserver How did we get the IP of the original nameserver to ask the question in the first place!?

We have created a version of the bootstrap paradox. How do we get around it? Nameservers are able to pass on information in a DNS request such as the authority section to provide information on which nameserver is currently responding, as well as an additional section to provide more information on the answer. In the case of nameservers, the additional section contains the IP addresses of the nameservers, to be used for the initial lookup – breaking the paradox. These are glue records, and they must be in the parent zone file. See the entry below for an example of authority along with additional sections in a DNS response:


It is interesting to note that some recursives will prefer the parent NS records for nameserver selection, others will prefer to query the child nameservers for child NS record, and still others will use the authority section within a DNS response handed out by those child nameservers. There could be differences in TTLs between the parent and child NS records, and even the number and content of the records themselves if you misconfigured them, or have a lame delegation in which one of the nameservers in delegation doesn’t respond to queries.

Is it, therefore, highly advisable that your parent and child nameservers match on both sides of the delegation, with all nameservers correctly responding. Of course, sometimes they can be different, in order to allow you to change nameservers. But, as a general rule, they should be the same. If you look at the example above, you will see the last two sections are almost identical, with a small but noticeable difference. “Matching RRsets” means: the algorithm in DNS doesn’t compare TTLs when looking for a match. It just looks at name, class, and type. This parent NS TTL set by the parent (including the TLD nameservers) within the parent zone, and there is nothing a child domain operator can do about it.

Delegation is the tool by which the DNS has become so scalable. By delegating control of zones to individual parties, yet having a central starting point in the root, DNS has been able to grow to billions of individual organizations. Through this network of DNS operations, it has been argued that the DNS is in fact the largest distributed network in the world. In our next installment, we will dive into the terms used for DNS administration and zonefile management.

Share Now

Matt Torrisi
Whois: Matt Torrisi

Matt Torrisi is a Senior Solutions Engineer at Oracle Dyn Global Business Unit, a pioneer in managed DNS and a leader in cloud-based infrastructure that connects users with digital content and experiences across a global internet.

Find out more about the fundamentals of DNS and how it actually functions in the real world.

Learn More

To current Dyn Customers and visitors considering our Dynamic DNS product: Oracle acquired Dyn and its subsidiaries in November 2016. After June 29th, 2020, visitors to will be redirected here where you can still access your current Dyn service and purchase or start a trial of Dynamic DNS. Support for your service will continue to be available at its current site here. Sincerely, Oracle Dyn