Domain Name System (DNS) delegation allows you to delegate responsibility for a domain or subdomain to another name server.
Delegation is a key function of DNS that enables the decentralized and distributed administration of domain names and IP addresses. But what specific type of DNS record is used to delegate a DNS zone?
NS Records Delegate DNS Zones
The primary type of DNS record used for delegating a DNS zone is the NS (Name Server) record. NS records are used to list the authoritative name servers for a domain or subdomain.
When a DNS resolver needs to look up a domain name, it starts from the root name servers and queries them to find the authoritative name servers for that domain. The root servers contain NS records listing the name servers for the top-level domains (TLDs) like .com and .net. The TLD servers then contain NS records for the second-level domains, and so on.
Each delegation point where responsibility for a domain is handed off contains an NS record pointing to the authoritative name servers for that zone. This chained delegation allows DNS to scale across the entire domain name space.
So in summary, NS records delegate responsibility for a DNS zone to a set of authoritative name servers. Configuring proper NS records is essential for setting up DNS delegation.
How Do NS Records Delegate A Zone?
NS records work together in sets to delegate zones. Here’s a quick example:
The parent zone example.com contains these NS records:
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
This delegates responsibility for the example.com zone to the two name servers ns1.example.com and ns2.example.com.
The child zone sub.example.com is delegated from example.com, so it contains these NS records:
sub.example.com. IN NS ns3.sub.example.com.
sub.example.com. IN NS ns4.sub.example.com.
This hands-off control of the sub.example.com subdomain to the two name servers ns3 and ns4.sub.example.com.
The NS records in the parent zone provide the glue records pointing to the authoritative name servers for the child. This allows the delegation to be followed recursively.
Steps for Configuring DNS Zone Delegation
Follow these steps to set up DNS zone delegation properly using NS records:
Create name servers – Set up at least two authoritative name servers for the child zone (e.g. ns3.sub.example.com and ns4.sub.example.com).
Configure NS records in the child zone – In the DNS configuration for the child zone, add NS records listing its name servers (e.g. ns3 and ns4).
Add glue records in the parent zone – In the parent zone, add A or AAAA records that provide the IP addresses for the child’s name servers. These glue records allow the NS delegation to be followed.
Add NS records in the parent zone – In the parent DNS configuration, create NS records pointing to the child’s name servers (e.g. ns3.sub.example.com and ns4.sub.example.com). This establishes the delegation.
Following these steps properly sets up delegation via NS records between parent and child zones.
Benefits of Using NS Records for DNS Delegation
There are several key benefits to using NS records to delegate DNS zones:
- Simplifies administration: Enables separately administered zones and distributed management.
- Improves performance: Localizes traffic and spreads load across multiple name servers.
- Limits impact of failure: Failures are isolated to a single zone versus affecting the entire DNS.
- Supports geolocation: Delegated zones can use name servers optimized for certain regions.
- Facilitates scaling: DNS can expand to billions of domain names using delegation.
By delegating zones with NS records, DNS can provide distributed, resilient, efficient name resolution for the entire internet.
Delegating Reverse DNS Zones
NS records are also used to delegate reverse DNS zones that handle reverse DNS lookups.
For example, the 192.168.10.in-addr-arpa zone handles reverse lookups for 192.168.10.x IP addresses. The parent 192.168.in-addr.arpa zone could delegate this to two name servers with NS records like this:
10.168.192.in-addr.arpa. IN NS ns1.isp.com.
10.168.192.in-addr.arpa. IN NS ns2.isp.com.
This allows the ISP to delegate control of reverse DNS to their own name servers. Proper reverse DNS delegation is important for handling PTR records and reverse lookups.
Alternative Methods of DNS Delegation
While NS records are the primary method of delegating DNS authority, there are some alternative methods:
- CNAME records – A CNAME can point a zone apex (e.g. example.com) to a set of name servers. However, this method is not preferred.
- DNS SRV records – Can delegate a service subdomain (e.g. _sip._tcp.example.com) to specific servers. Useful for microservice architectures.
- Anycast – Uses BGP routing tricks to delegate zones to multiple servers with the same IP address. Requires advanced networking.
However, NS records are the standard and most widely supported approach to delegating zones in DNS. The other methods have limitations or special use cases.
Troubleshooting DNS Delegation Issues
If there are problems accessing a delegated DNS zone, here are some things to check:
- Confirm the parent zone contains NS records pointing to the child name servers.
- Verify the glue A/AAAA records exist in the parent zone.
- Check firewalls and security groups to ensure TCP/UDP port 53 access to name servers.
- Validate DNS resolver can reach child name servers (e.g. ping or dig @nameserver).
- Review name server configuration and restart services if needed.
- Check for NS record errors like typos or incorrect name servers listed.
Proper DNS delegation is crucial for accessing delegated zones and subdomains. Diagnosing delegation issues helps avoid dead ends in name resolution.
Invalid Zone Delegation Can Break Name Resolution
If zone delegation is not configured correctly, it can lead to resolution failures. Some examples of incorrect DNS delegation:
- Missing or incorrect NS records in the parent zone.
- No glue records or invalid IP addresses in glue records.
- Only one NS record/name server (at least two are needed for redundancy).
- NS records list non-existent name servers.
- Zone apex delegated to external name servers incorrectly.
Any such improper delegation can cause delegated zones to become unreachable. DNSSEC-signed zones may also fail validation checks if delegation is broken.
Careful planning and validation of delegation configuration help avoid these authoritative name server failures.
Using Delegation to Segment DNS Infrastructure
With complex DNS infrastructures, zone delegation can be very useful for segmentation and access control.
For example, a large enterprise could delegate subdomains to different teams:
engineering.company.com > Engineering team name servers
marketing.company.com > Marketing team name servers
sales.company.com > Sales team name servers
This allows each team to manage their own DNS zone independently. It segments DNS administration and prevents cross-team access.
DNS delegation enables more granular control and security zoning even when using centralized corporate DNS servers. Segmentation helps limit the blast radius from any issues with a delegated zone.
Delegating New gTLDs and ccTLDs
ICANN uses DNS delegation heavily in managing DNS root zone changes and adding new TLDs:
- Adding a new gTLD like .example requires delegating from the root.
- Delegating a new ccTLD like .us requires updating .arpa zone.
- DNSSEC key changes are propagated via delegation.
The root zone relies on delegating zones to regional internet registries and registrars. DNSSEC was developed to secure these critical delegations. Proper use of NS records and delegation helps ensure DNS root scaling and stability as TLDs expand.
Best Practices for DNS Delegation
Some tips for configuring delegation with NS records:
- Always delegate using name servers, not CNAMEs.
- Create at least 2 name servers for redundancy and failover.
- Use descriptive names for name servers like ns1.domain.com.
- Validate glue records exist in the parent zone before changing delegation.
- Monitor name server performance and load after delegating.
- Establish proper forwarding from parent to child name servers.
- Use DNSSEC to sign zones and secure the delegation chain.
Properly configuring delegation is a core DNS administration skill for operating resilient domains.
Delegation Between TLDs and Domain Registrars
One very common use of DNS delegation happens between TLD registries and domain name registrars.
For example:
- The .com TLD is operated by Verisign with global name servers.
- When you register example.com, your registrar delegates to your own name servers via NS records in .com.
- Your name servers become authoritative for your domain.
This Registry/Registrar model relies heavily on DNS delegation to segment authority over individual domain names. The registry ??? Registrar delegation links domain registration with DNS resolution.
Using Subdomain Delegation for Multi-Site Web Hosting
Shared web hosting providers often use subdomain delegation to segment customers:
- Parent zone ns1.shared-hosting.com is hosted on provider name servers
- Customer A gets a.shared-hosting.com delegated to their own name server
- Customer B gets b.shared-hosting.com delegated
This allows the provider to offer isolated, delegated hosting for multiple customers. DNS authority is delegated at the subdomain level.
Delegating subdomains also allows customers to manage their own DNS independently. Customers can run their own name servers with full control over records.
Conclusion
In conclusion, NS records are the primary DNS resource records used to delegate zones and configure authoritative name servers. NS records provide a decentralized method for DNS administrators to divide control and isolate zones across different name servers.
Proper configuration of zone delegation is essential for constructing a scalable DNS infrastructure. Understanding how to delegate with NS records is a key skill for any system administrator working with DNS.
