Zone delegation in the DNS is how a parent zone signals to DNS resolvers that authority for a child zone is served by (or delegated to) a different set of servers.
This is a fundamental part of the DNS. The DNS is very large, and each zone is owned and managed independently. For example, the .com zone is managed by Verisign, while the google.com zone is managed by Google. Verisign delegated that zone to Google.
Delegations are NS records
A delegation is a set of name server (NS) records which list the DNS host names of the name servers that are authoritative for the domain. Like all DNS records, each NS record has a time-to-live (TTL) in seconds. Each NS record has one data field: the DNS host name of a name server. This host name must resolve, through the DNS, to an IP address where DNS server software is running and available to respond to DNS queries.
Using the reserved domain example.org, a set of NS records for the zone example.org might look something like the example below. This same set of NS records would actually exist in both the example.org zone and the org zone, and we’ll discuss that wrinkle in more detail later.
example.org. 86400 NS ns1.example.org.
example.org. 86400 NS ns2.example.org.
example.org. 86400 NS ns3.example.org.
example.org. 86400 NS ns4.example.org.Name servers are often named “ns1”, “ns2”, etc., but they can be named anything. They can be either inside the zone they serve, or they may be in another zone altogether.
There is no requirement to have a particular number of NS records for a zone, but a de facto standard is to have four identical NS records in both the delegation and authoritative NS record sets. Too few NS records leads to fragility in case of outage, and too many leads to DNS responses that are larger than necessary.
It all starts at the root
Now that we know what an NS record looks like, how are they used? The DNS is a top-down distributed database of DNS names beginning with the root zone at the apex. The root zone is commonly referred to by a single period or dot character: “.“. All DNS recursive resolvers come pre-configured with a list of the IP addresses of the DNS name servers for the root zone. These are often called root servers. Today there are 13 root servers. Each has one IPv4 address and one IPv6 address, so there are actually 26 root server IP addresses.
In the past, each IP was a distinct server. Today, these IP addresses are anycasted — each hosted by many servers scattered around the globe. The root servers are operated by many different entities including ICANN, Verisign, the Internet Systems Consortium (ISC, the makers of BIND), NASA, the US army, universities, and others. The operation of these root servers is very serious business indeed. Without them, the Internet would cease to function.
Delegating to children
Each DNS zone, especially the root zone, may have child zones that are owned and operated by a different entity. To signal to recursive resolvers that authority for a child zone has been delegated, the owner of the parent zone inserts a set of NS records at that name in the parent zone.
When a recursive resolver encounters this set of NS records, they will resend the DNS query to the name servers authoritative for the child zone. This process may repeat a number of times during resolution of a single name.
Recursion in action
So for example, if a recursive resolver is asked to resolve www.example.org, it will first send the query to one of its pre-configured root servers. The root server does not know anything about the example.org zone, but it does have a delegation for the top-level zone org, so it will respond with a delegation containing the name servers for org.
An example of zone delegation.
Next, the resolver will send the same DNS query to one of the name servers for org. This server will not know the answer either, but it will have a delegation for example.org, and so it will return the list of name servers for example.org to the recursive resolver. The resolver is now a step closer.
Finally, the recursive resolver will use the list of name servers it just received for example.org to send the DNS query to one of the name servers for example.org. This server will know the answer and so will respond with the address records or perhaps a CNAME record for www.example.org. The recursive resolver will then return that answer to its client, and the application will be able to open a web page or perform some other operation for the user.
In this example, there were only two delegations, but there could be more. There is no hard limit on the number of delegations that might be required to resolve a name. In theory, there could be up to 128, but that would be very strange. Generally, five or six delegations would be considered high.
Caching
Delegation may seem an expensive process since a recursive resolver must send the same DNS query multiple times to multiple servers, and that is certainly true at times. Each query takes 20-60 milliseconds or more, which means that a web page will load that much slower. The good news is that caching is fundamental to the DNS.
The first time a DNS resolver is asked to resolve a name from a “cold” cache with no entries, it will have to send one query for each level of delegation. The NS records in each delegation will be cached for their TTL, which will generally be for several hours or even days. The next time a client wants to resolve a name in that zone, the resolver will use the cached NS records to send the query directly to the server authoritative for the name. So, name resolution will usually be much faster once a resolver’s cache has warmed up.
Selecting your NS TTL
Registrars often select the TTLs for delegation NS records on behalf of their clients, but it’s best to use relatively long TTLs in delegations. A TTL of one day is common. TTLs shorter than one hour are not recommended, nor are TTLs longer than a week. You may use the same TTL in both the delegation NS record set and the authoritative record set.
The duality of NS records
The root of a zone must always contain one SOA record and a set of NS records listing the authoritative name servers for the zone. For more information about the SOA record and the root of a zone, see our article on the SOA record type. The parent zone delegation is also a set of NS records for the name of the child zone. These two NS record sets exist in the DNS at the same time at the same name. Delegation points are unique in the DNS in this respect. One NS record set exists in the parent zone and one exists in the child zone at the same DNS name.
For example, the administrator for example.org created an SOA and a set of NS records at example.org. These records exist in the example.org zone. When the administrator is ready to open the zone up to the Internet, he instructs his registrar to create a delegation in the org zone. The delegation is a set of NS records, often identical to those at example.org, but these records are in the org zone.
So there are actually TWO sets of NS records for every zone: the authoritative NS record set in the child zone and the delegation NS record set in the parent zone. It is recommended that these NS record sets be identical, but they do not have to be. Generally speaking, DNS resolvers can use either set of NS records. When a resolver has access to both, it will prefer the authoritative NS record set from the child zone. The way DNS data should be preferred, or ranked, by resolvers is specified in RFC 2181 section 5.4.1.
Gluing the DNS together
Glue records are extra copies of DNS address records, either type A for IPv4 addresses or type AAAA for IPv6 addresses. Glue records are included in the parent zone. They can be critical for the operation of a DNS zone. One common scenario is called “inside zone glue” because the glue records are for data inside the zone. Consider this common pattern of delegation:
example.org. 86400 NS ns1.example.org.
example.org. 86400 NS ns2.example.org.The name server host names ns1 and ns2 are inside the zone they serve. There is a chicken-and-egg problem lurking here, though: how does a DNS resolver find the IP addresses of ns1.example.org and ns2.example.org? To resolve those names, the resolver would have to follow the delegation, but following the delegation is impossible without knowing the IP addresses! The solution to this problem is glue records.
The parent zone contains not only the delegation shown above, but it also contains glue records such as the ones below. It is common to include at least one glue record for each name server host name in the delegation. Registrars will usually require this and may not permit a delegation without glue.
ns1.example.org. 86400 A 1.2.3.4
ns2.example.org. 86400 A 1.2.3.5When the parent zone generates a DNS delegation response, it includes both the NS record set and all the glue records that the resolver will need to contact the name servers for the child domain. Thus, DNS resolvers are spared the impossible chicken-and-egg problem of trying to use the delegation to resolve DNS server host names within the delegation.
Missing or deleted delegations
There are two common causes of problems with delegation. The first is that the delegation may simply be missing. If the registrar or parent zone administrator has not yet added the delegation or if it has been accidentally deleted, then clients who are trying to resolve a name below the delegation will receive a non-existent name (NXDOMAIN) error. This is because if the delegation is not present in the parent zone, then by definition all names below the delegation do not exist in the DNS.
Lame delegations
Another common problem with delegations is that they might be “lame”, which is to say that the name server names in the NS records are not correct. RFC 8499 has a good technical definition of lame delegation. For example, suppose the parent zone delegation is:
example.org 86400 NS ns1.example.org.
example.org 86400 NS ns2.example.org.Also, suppose these names were correct last week but yesterday the DNS administrator replaced some name servers with new machines. However, they forgot to tell the registrar and now the delegation should actually be:
example.org 86400 NS rainier.example.org.
example.org 86400 NS denali.example.org.In this scenario, the old records are said to be lame as soon as the old name servers are turned off. At this point, recursive resolvers will be unable to connect to any name servers for the zone through the delegation. Resolvers will attempt resolution a few times and then give up. Clients will usually receive a DNS server failure (SERVFAIL) error.
It’s important as a DNS administrator to remember that when the DNS servers for a zone are updated, any changes must be communicated clearly to the registrar. It’s also a good idea to plan for a period of overlap at least as long as the NS record TTL when replacing servers. Changing the NS records one by one instead of all at once is also advisable.
Privacy
In recent years, DNS privacy has become an important and controversial topic. One issue with the way that DNS resolvers historically work is that they send the full query name to all the name servers in the entire delegation chain. This reveals the names that are being resolved by end users unnecessarily. For example, the DNS root servers do not need to know that a user is resolving www.example.org in order to provide the delegation for org. They only need to be told that someone is trying to resolve a name that has org as the right-most label.
To address this concern and increase DNS privacy for end users, many DNS resolver implementations now include “DNS Query Name Minimisation”, which was originally defined in RFC 7816 and later updated by RFC 9156. This RFC was designed so that DNS delegation and zone data does not need to be changed, so there is no added burden on DNS administrators.
Tools
There are a number of tools that can be used to test delegations. The popular command line tool “dig” (included in ISC BIND) has a “+trace” option that will perform queries from the root down through delegations. dnsviz.net is another popular tool, but the output can be confusing to DNS novices as it is primarily focused on DNSSEC.