DNS Delegation: Concepts and Best Practices

DNS delegation is a crucial aspect of managing large and complex DNS infrastructures. It allows organizations to divide their DNS zones into smaller, more manageable parts and delegate authority to different groups or individuals. Delegation is actually one of the foundations of the entire DNS system since it allows responsibility for different portions of domains to be divided, providing flexibility and other benefits. 

In this article, we will explore the best practices for DNS delegation, including how to avoid common difficulties and ensure optimal performance and security. Whether you’re an IT professional responsible for managing a large DNS infrastructure or just curious about how DNS works, this article will provide you with valuable insights into DNS delegation and its benefits. Let’s get started!

Summary of key DNS delegation concepts

Here is a brief summary of what will be covered in this article.

Definition of DNS delegation

As you likely know, to “delegate” something means to transfer some responsibility for one or more tasks to another person or entity. The same term is used in the DNS world, where the process is called DNS zone delegation (or sometimes simply DNS delegation). 

DNS delegation is the process by which a parent DNS zone indicates to DNS resolvers that it has delegated the authority for a DNS subzone (or child zone) to a different set of DNS servers. This allows the DNS resolvers to locate and query the delegated DNS servers for the subzone’s DNS records.

DNS delegation benefits

Using DNS delegation can provide a number of advantages to a DNS administrator and the organization as a whole:

• Improved performance: By delegating a portion of your DNS namespace to a different set of DNS servers, you can improve performance by reducing the load on your primary DNS servers.
• Simplified DNS management: DNS delegation can simplify DNS management by allowing different teams or locations to manage their own DNS configurations.
• Integration with third-party services: DNS delegation allows you to integrate with third-party services, such as content delivery networks (CDNs), cloud-based email services, or tracking services, that require you to delegate DNS management for a portion of your DNS namespace to their own DNS servers.

DNS delegation applications

The various benefits of DNS delegation described above apply to many uses of DNS. However, they dictate a number of situations where DNS delegation can be especially useful. 

Common DNS delegation applications include situations where the following are needed:

• Distribution of responsibility: You have multiple departments or subsidiaries and need to delegate responsibility for DNS management to different teams or locations.
• Subdomain specialization: You want to create a subdomain for a website or web application that requires separate DNS management or would benefit from it.
• Performance enhancement: You want to take advantage of load distribution and geographic distribution to optimize DNS query responses. By delegating subzones to different DNS servers, organizations can efficiently distribute query load. In addition, strategically delegating to DNS servers in different geographic locations ensures that users receive faster DNS responses by connecting to the servers closest to their location. By incorporating these techniques, organizations can enhance performance, optimize resource utilization, and provide a faster and more efficient DNS resolution experience for their users. 
• Subdomain outsourcing: You may need to use a subdomain for a specific purpose that involves external management. For example, many organizations create a separate subdomain specifically for email marketing purposes and delegate it to a specialized email service company that handles the technical aspects of email authentication and sender reputation.

Understanding zones and subzones

DNS organizes authoritative information into units called zones. A zone is essentially a portion of the DNS namespace for which a particular DNS server is authoritative. Each zone contains a set of resource records that define the DNS information for that zone.

Zones are distributed to both primary (main) and secondary (backup) name servers, which respond with authoritative answers for those zones. The purpose of distributing zones to multiple servers is to ensure redundancy and availability in case one or more servers become unavailable.

There are two types of zones: forward-mapping and reverse-mapping. Forward-mapping zones are used to map hostnames to IP addresses, while reverse-mapping zones are used to map IP addresses to hostnames. Both types of zones include the same basic set of information:

• Zone name
• Start Of Authority (SOA) record
• NameServer (NS) records
• Other resource records (optional)

The image below shows an example of a BIND format forward mapping zone.n essential part of DNS monitoring. Key considerations in this area include geo-based DNS routing, watching DNS latency, and monitoring DNS servers.tation for robust API development. A well-crafted API architecture in an evolving digital landscape remains pivotal, enabling efficient communication and collaboration between systems.

A subzone, also referred to as a child zone, is a division of a zone that shares the latter parts of the domain name with the parent. For instance, if the parent domain name is company.com, a subzone could be sales.company.com, as shown below. Like a zone, a subzone is a group of DNS records that are managed together for administrative convenience. Typically, subzones are created to meet specific organizational requirements, such as separating different departments or regions within a company.

While the terms “subzone” and “delegated zone” may cause some confusion, it’s important to note that a delegated zone is essentially a subzone, but with the difference that the delegated zone is managed on separate DNS servers from the parent zone, unlike a subzone. We will have a whole section comparing these two concepts later in this article.

How DNS delegation works

DNS was designed over three decades ago. It has scaled well even as the size of the Internet has dramatically increased and DNS management requirements have increased with it specifically because delegation essentially decentralizes management. Let’s take a look at how delegation works in detail using the example outlined above.

In the previous subzone example, the DNS administrator of company.com is still responsible for the subzone. However, let’s say that the sales department has specific needs and no longer wants to follow the rules of the DNS administrator of company.com; it wants to set up its own DNS servers and manage sales.company.com with its own parameters. The sales department then needs to work with the DNS administrator of company.com to set up delegation, so the authority for sales.company.com is delegated to a new set of DNS servers managed by the sales department.
Effective delegation involves close collaboration between the parent and child zones. Specifically, the parent zone must include NS records for the child’s new authoritative servers (primary and secondary) to refer to other recursive resolvers, as shown in the following figure. These are called glue records and are explained further below.

Actually, DNS delegation is happening all the time because it all begins from the very base: the root domain. Delegation in DNS happens hierarchically, from the root domain down to the domain name in question. Here is an overview of how delegation happens when you query a domain name, let’s say www.example.com.

When the DNS resolver (typically at your ISP) receives the DNS query from the client, it checks in its cache. If it does not have the IP address it needs in the cache and does not have any forwarding configuration, by default, it sends an iterative query to the root name servers. The root name server’s IP addresses (both IPv4 and IPv6) are stored in a file known as “root hints,” which is part of any recursive resolver.
The root server answers with a referral, since it is authoritative for part of the requested fully qualified domain name (FQDN) — only the very last part of the name, which in this case is .com. It includes the NS records for the delegated domain. For instance, if the requested domain is www.example.com, the root server would provide a list of .com name servers, since that’s the highest level, as shown below.

com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.

After receiving a referral message from a root server with a list of .com name servers, the recursive resolver caches the information. Then it chooses a name server from the list and sends it an iterative query.

The delegated domain’s name server responds with a referral since it is authoritative for part of the requested domain. In the referral message, it sends the NS records for the delegated domain. If the requested FQDN is www.example.com, the .com server would respond with a list of example.com name servers.

example.com.		172800	IN	NS	a.iana-servers.net.
example.com.		172800	IN	NS	b.iana-servers.net.

After caching the answers from the previous step, the recursive resolver continues the process, sending an iterative query for the FQDN to a chosen name server (e.g., a.iana-servers.net). Once the example.com name servers are reached, the authoritative name server sends an Authoritative Answer (AA) field-set answer back to the resolver, including valid responses such as NXDOMAIN, or in the case of this example, the A record.

www.example.com.		86400 	IN	A	93.184.216.34

The image below illustrates the process described above, showing a DNS resolution trace from root DNS servers down to the example.com domain authority. You can find the tool used for this here.

Glue records

Glue records are essential to delegation as they provide (in the form of A and AAAA records) information to connect the parent domain to the child domain. They are used to help resolve circular dependencies between domain names and their corresponding name servers. 
Let’s look at the delegation example again. The parent zone company.com is delegating sales.company.com to the ns1.sales.company.com and ns2.sales.company.com name servers. Now, since we are using name servers that are a child of the zone it’s being applied to (e.g. ns1.sales.company.com is a child of sales.company.com), we need to use glue records to know where these name servers are (by their corresponding IP addresses). Otherwise, it will get stuck in a resolution loop. So, the parent zone (company.com) includes not just the delegation (NS records) but also includes the A (AAAA if needed) records that map (or glue) the nameserver’s names to their IP addresses.

sales.company.com. IN NS ns1.sales.company.com.
sales.company.com. IN NS ns2.sales.company.com.
ns1.sales.company.com. IN A 2.2.2.2
ns2.sales.company.com. IN A 3.3.3.3

Subzone and delegation comparison

As the administrator of a parent zone, it’s important to consider the appropriate use of subzones and delegation. To maintain control over a child zone and store its data on the same servers as the parent zone, subzones are the way to go. However, if you want the child zone to have its own administrative control and store its data on separate servers, delegation is the better option.

In internal-only domain configurations, delegation is rarely necessary, while subzones are much more commonly used.

Lame delegation

Lame delegation refers to a problematic situation where the parent domain attempts to delegate a child domain to a specific set of name servers that are either not authoritative for the zone or not operational with DNS services. Let’s take a look at these common scenarios of lame delegation. You can also find technical definitions in RFC 8499 and RFC 1912.

The image below illustrates a scenario where the parent zone (company.com) responds with a referral that includes incorrect glue records pointing the recursive resolver to an incorrect or unreachable IP address. When the recursive DNS follows this referral, it turns out that it cannot resolve the domain name since the IP addresses are unreachable (servers down) or are available but are not running any DNS service (timeout). The client would likely experience some delay and eventually receive a “SERVFAIL” response code from the recursive DNS resolver.

Imagine now (as shown in the image below) that the recursive resolver receives a referral from the parent zone where just one of the name servers is correct. Server 2.6.6.6 is not authoritative for sales.company.com, and every time the resolver queries the name server 2.6.6.6 for an authoritative answer, it won’t get any response and will start over again from the root servers. In this example, the recursive resolver has a 50% probability (assuming that it uses a round-robin mechanism) of selecting the correct name server with IP address 2.2.2.2, as there are two NS records provided by the parent zone. To end-users, the issue may appear as slow name resolution, as the recursive resolver continues to loop around repeatedly until it reaches the final authoritative name server at 2.2.2.2, or until a timeout occurs.

In conclusion, lame delegations can cause DNS resolution errors and slow down the process of resolving domain names, as queries for the delegated subdomain are repeatedly referred to the lame DNS server. They can be identified by analyzing DNS query logs. Lame delegation can be resolved by correcting the configuration of the DNS server and keeping it updated or by delegating the subdomain to a different DNS server that is able to provide valid responses. 

Best practices in DNS delegation 

Effective delegation of DNS zones is crucial for maintaining a reliable and highly available DNS infrastructure. When delegation is done properly, it allows for efficient resolution of DNS queries and minimizes the risk of issues. In this section, we will discuss some best practices to follow when delegating DNS zones to ensure optimal performance and security of your DNS infrastructure.

• Maintain accuracy: Ensure that the delegated zone’s NS records are up to date and accurately reflect the current set of authoritative name servers. By doing this, you can avoid lame delegation issues. This can be achieved by regularly monitoring the status of the delegated name servers, ensuring that they are properly configured and functioning correctly.
• Use at least two authoritative name servers: Delegating a domain to only one name server can lead to single points of failure, which can cause downtime for the domain. To ensure that your domain remains available, it is recommended to use at least two name servers that are located in different geographic regions.
• Prioritize communication and documentation: Clear communication among all the parties involved is essential for effective DNS delegation. Ensure that everyone understands their roles and responsibilities, and create thorough documentation that provides a record of what has been delegated and who is responsible for each part of the process.
• Regularly monitor DNS health and configuration: Monitor your DNS servers and zone files frequently to ensure that they are performing optimally and are free from errors. Use DNS monitoring tools to detect issues before they become critical and impact your online services.

Summary of key concepts

DNS delegation is a fundamental part of the Internet that allows it to be efficiently maintained despite its huge size and complexity. When organizations delegate DNS responsibilities to different teams or locations, they can simplify DNS management, enhance performance, and incorporate third-party services. However, to ensure the safety and reliability of DNS infrastructure, it’s important to use best practices such as those outlined in this article. By implementing DNS delegation correctly, organizations can ensure efficient DNS management and minimize potential DNS infrastructure problems.

FAQs