DNS Delegation: Concepts and Best Practices

DNS delegation is a crucial aspect of managing large and complex DNS infrastructures. It allows organizations lớn divide their DNS zones into smaller, more manageable parts and delegate authority lớn 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 lớn be divided, providing flexibility and other benefits. 

In this article, we will explore the best practices for DNS delegation, including how lớn 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, lớn “delegate” something means lớn transfer some responsibility for one or more tasks lớn 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 lớn DNS resolvers that it has delegated the authority for a DNS subzone (or child zone) lớn a different phối of DNS servers. This allows the DNS resolvers lớn locate and query the delegated DNS servers for the subzone’s DNS records.

{{banner-23="/design/banners"}}‍

DNS delegation benefits‍

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

• Improved performance: By delegating a portion of your DNS namespace lớn a different phối 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 lớn manage their own DNS configurations.
• Integration with third-party services: DNS delegation allows you lớn integrate with third-party services, such as nội dung delivery networks (CDNs), cloud-based gmail services, or tracking services, that require you lớn delegate DNS management for a portion of your DNS namespace lớn their own DNS servers.

DNS delegation applications‍

The various benefits of DNS delegation described above apply lớn 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 lớn delegate responsibility for DNS management lớn different teams or locations.
• Subdomain specialization: You want lớn create a subdomain for a trang web or trang web application that requires separate DNS management or would benefit from it.
• Performance enhancement: You want lớn take advantage of load distribution and geographic distribution lớn optimize DNS query responses. By delegating subzones lớn different DNS servers, organizations can efficiently distribute query load. In addition, strategically delegating lớn DNS servers in different geographic locations ensures that users receive faster DNS responses by connecting lớn the servers closest lớn 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 lớn use a subdomain for a specific purpose that involves external management. For example, many organizations create a separate subdomain specifically for gmail marketing purposes and delegate it lớn a specialized gmail service company that handles the technical aspects of gmail authentication and sender reputation.

{{banner-24="/design/banners"}}

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 phối of resource records that define the DNS information for that zone.

Zones are distributed lớn both primary (main) and secondary (backup) name servers, which respond with authoritative answers for those zones. The purpose of distributing zones lớn multiple servers is lớn 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 lớn map hostnames lớn IP addresses, while reverse-mapping zones are used lớn map IP addresses lớn hostnames. Both types of zones include the same basic phối 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.

A subzone, also referred lớn as a child zone, is a division of a zone that shares the latter parts of the domain name name with the parent. For instance, if the parent domain name 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 lớn 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 lớn 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 lớn follow the rules of the DNS administrator of company.com; it wants lớn phối up its own DNS servers and manage sales.company.com with its own parameters. The sales department then needs lớn work with the DNS administrator of company.com lớn phối up delegation, sánh the authority for sales.company.com is delegated lớn a new phối 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) lớn refer lớn 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 name. Delegation in DNS happens hierarchically, from the root domain name down lớn the domain name name in question. Here is an overview of how delegation happens when you query a domain name 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 mặc định, it sends an iterative query lớn the root name servers. The root name server’s IP addresses (both IPv4 and IPv6) are stored in a tệp tin 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 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 name. For instance, if the requested domain name is www.example.com, the root server would provide a list of .com name servers, since that’s the highest level, as shown below.

Name servers for the .com top-level domain

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 name. In the referral message, it sends the NS records for the delegated domain name. If the requested FQDN is www.example.com, the .com server would respond with a list of example.com name servers.

Name servers for the example.com domain‍

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 lớn 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 lớn 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 lớn the example.com domain name authority. You can find the tool used for this here.

{{banner-25="/design/banners"}}

‍

Glue records

Glue records are essential lớn delegation as they provide (in the size of A and AAAA records) information lớn connect the parent domain name lớn the child domain name. They are used lớn help resolve circular dependencies between domain name names and their corresponding name servers. 

Let’s look at the delegation example again. The parent zone company.com is delegating sales.company.com lớn 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 lớn (e.g. ns1.sales.company.com is a child of sales.company.com), we need lớn use glue records lớn 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 lớn 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 lớn 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 lớn go. However, if you want the child zone lớn have its own administrative control and store its data on separate servers, delegation is the better option.

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

Lame delegation

Lame delegation refers lớn a problematic situation where the parent domain name attempts lớn delegate a child domain name lớn a specific phối 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 lớn an incorrect or unreachable IP address. When the recursive DNS follows this referral, it turns out that it cannot resolve the domain name 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 lớn 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 name names, as queries for the delegated subdomain are repeatedly referred lớn 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 lớn a different DNS server that is able lớn provide valid responses. 

{{banner-26="/design/banners"}}

‍

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 lớn follow when delegating DNS zones lớn ensure optimal performance and security of your DNS infrastructure.

• Maintain accuracy: Ensure that the delegated zone’s NS records are up lớn date and accurately reflect the current phối 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 name lớn only one name server can lead lớn single points of failure, which can cause downtime for the domain name. To ensure that your domain name remains available, it is recommended lớn 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 lớn ensure that they are performing optimally and are không tính phí from errors. Use DNS monitoring tools (like Catchpoint) and alerting services lớn 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 lớn be efficiently maintained despite its huge size and complexity. When organizations delegate DNS responsibilities lớn different teams or locations, they can simplify DNS management, enhance performance, and incorporate third-party services. However, lớn ensure the safety and reliability of DNS infrastructure, it’s important lớn 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.