Delegating a subdomain to a different DNS server means you’re telling the internet, "Hey, for anything that ends in sub.example.com, don’t ask my main DNS server anymore; ask this other DNS server instead." It’s like giving a specific department its own dedicated switchboard operator instead of routing all calls through the main reception.
Let’s see this in action. Imagine you have example.com managed by your main DNS provider, and you want api.example.com to be handled by a specialized service, maybe for faster DNS lookups or specific security features.
Here’s how you’d set it up.
1. At your Parent DNS Zone (example.com):
You need to create "NS" (Name Server) records. These records point to the DNS servers that will be authoritative for your subdomain.
Let’s say your subdomain is api.example.com and the DNS servers responsible for it are ns1.api-dns.com and ns2.api-dns.com.
You’d add these records to your example.com zone file (or configure them via your DNS provider’s control panel):
; Zone file for example.com
@ IN SOA ns1.example.com. admin.example.com. (
2023102701 ; Serial
3600 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ; Minimum TTL
)
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
mail IN A 192.168.1.10
www IN A 192.168.1.20
api IN NS ns1.api-dns.com. ; <--- This is the delegation
api IN NS ns2.api-dns.com. ; <--- This is the delegation
; ... other records for example.com
Notice the api IN NS ns1.api-dns.com. and api IN NS ns2.api-dns.com.. This tells the world: "If you’re looking for api.example.com or any of its sub-subdomains, go ask ns1.api-dns.com or ns2.api-dns.com."
2. At your Subdomain’s DNS Servers (api-dns.com):
Now, the DNS servers ns1.api-dns.com and ns2.api-dns.com need to be configured to actually host the api.example.com zone. They need to know what IP addresses to return for api.example.com and anything under it.
On ns1.api-dns.com and ns2.api-dns.com, you’d have a zone file for api.example.com that looks something like this:
; Zone file for api.example.com
@ IN SOA ns1.api-dns.com. admin.api-dns.com. (
2023102701 ; Serial
3600 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ; Minimum TTL
)
@ IN NS ns1.api-dns.com. ; <--- These MUST match the NS records above
@ IN NS ns2.api-dns.com. ; <--- These MUST match the NS records above
@ IN A 10.0.0.1 ; IP for api.example.com itself
app1 IN A 10.0.0.2 ; IP for app1.api.example.com
db IN A 10.0.0.3 ; IP for db.api.example.com
Crucially, the NS records within the api.example.com zone must point back to the names you specified in the parent zone’s NS records. This creates the chain of trust.
The Mental Model:
Think of DNS as a hierarchical phone book. The root servers know where to find the .com phone book. The .com phone book knows where to find the example.com phone book. Delegation is like saying, "For all numbers starting with 555 in the example.com phone book, don’t look in the main example.com book; there’s a special 555-numbers.example.com book that has those."
The parent zone (example.com) provides the pointer (the NS record) to the child zone’s authoritative servers (api-dns.com). The child zone’s servers then hold the actual records for the subdomain (api.example.com).
The key problem delegation solves is scalability and management. If example.com has millions of subdomains or is managed by different teams, you don’t want one massive, unwieldy zone file. You can delegate marketing.example.com to a marketing team’s DNS server, dev.example.com to a dev team’s server, and api.example.com to an API platform’s server. Each can manage their own records independently.
Now, here’s something most people overlook: glue records. When you delegate api.example.com to ns1.api-dns.com, the DNS resolver needs to know the IP address of ns1.api-dns.com to actually reach it. If ns1.api-dns.com’s IP address is also within the api.example.com domain (e.g., ns1.api.example.com), you’d have a circular dependency. The resolver would need the IP of ns1.api.example.com to find the NS records for api.example.com, but the NS records for api.example.com point to ns1.api.example.com, and you can’t look up the IP for ns1.api.example.com until you know its NS records. To break this, the parent zone (example.com) must provide "glue records." These are A records for the subdomain’s name servers, placed in the parent zone.
So, in example.com’s zone file, you’d also need:
; Zone file for example.com (with glue records)
; ... other records ...
api IN NS ns1.api-dns.com.
api IN NS ns2.api-dns.com.
ns1 IN A 192.0.2.100 ; Glue record for ns1.api-dns.com
ns2 IN A 192.0.2.101 ; Glue record for ns2.api-dns.com
; ... other records ...
(Note: In the example above, ns1.api-dns.com and ns2.api-dns.com are external to example.com. If they were internal like ns1.api.example.com, then the glue records would be ns1 IN A 192.0.2.100 and ns2 IN A 192.0.2.101 directly under the api subdomain’s NS records in the parent zone.)
This provides the necessary IP address for the resolver to contact the delegated name server directly, bypassing the circular dependency. Without glue records, the delegation wouldn’t work for name servers that are themselves within the delegated domain.
The next step in mastering DNS infrastructure is understanding how DNSSEC is implemented across delegated zones.