DNS NS Delegation for CDN: Offloading Domain Resolution to Edge Networks

I still remember getting paged at 2 AM because a retail customer's authoritative DNS servers melted during a flash sale. They'd kept all their domain resolution in-house on two aging BIND boxes, and when traffic spiked to 18 million queries per hour, those boxes just stopped answering. We fixed it that night by moving them to NS delegation, pushing the entire delegated zone onto our edge network's anycast DNS. Their origin DNS load dropped 96% overnight and never became a problem again. That's the quiet power of DNS delegation for CDN.

What NS Delegation Actually Does: Handing Off Authority, Not Just Pointing

Most folks first encounter CDN DNS through a simple CNAME — you create www.example.com CNAME www.example-cdn.net and call it a day. That works, but you’re not really offloading anything. Your authoritative servers still get hit for every initial lookup, and you’re still responsible for the uptime, scaling, and global distribution of your DNS itself. NS delegation is different. You’re creating a zone cut and telling the parent zone: “Don’t ask me anymore, ask these name servers instead.” For CDN DNS engineering, that shift is fundamental.

When you delegate something like cdn.example.com or even www.example.com as its own zone to your CDN provider's name servers (say, ns1.cdn-edge.net through ns4.cdn-edge.net), you’ve completely transferred authority for that branch of your domain. The parent — your main example.com zone — just holds the NS records and crucially, the glue records. From that point on, every domain resolution query for hosts under that delegated name goes straight to the edge network's DNS infrastructure. I've seen teams confuse this with DNS CNAME Flattening: Pointing Root Domains to CDN Without Breaking DNS Rules which solves a different problem at the apex; flattening pretends a CNAME can live at the root, while NS delegation creates a legitimate, standards-compliant zone cut.

That authority transfer matters because modern CDN DNS isn't just responding with a static IP. Once the CDN's authoritative servers own the zone, they can make dynamic, per-query decisions — returning different A/AAAA records based on real-time load, health checks, or the client's network proximity. We couldn't do that effectively if we were just answering a CNAME from your infrastructure. The delegation lets us integrate routing logic directly into the DNS response, which is how you get true edge steering instead of just a redirect.

; Parent zone: example.com
; This is the ONLY thing your origin DNS needs to serve for the delegated branch
cdn     IN  NS  ns1.cdn-edge.net.
cdn     IN  NS  ns2.cdn-edge.net.
cdn     IN  NS  ns3.cdn-edge.net.
cdn     IN  NS  ns4.cdn-edge.net.

; Glue records - required if the NS names are inside the delegated zone
; Without these, resolvers get stuck in a loop
ns1.cdn-edge.net.  IN  A   192.0.2.10
ns2.cdn-edge.net.  IN  A   192.0.2.11
ns3.cdn-edge.net.  IN  AAAA 2001:db8::10

; On the CDN's authoritative servers, the delegated zone:
; cdn.example.com zone file
$ORIGIN cdn.example.com.
@       IN  SOA ns1.cdn-edge.net. hostmaster.cdn-edge.net. 2024010101 3600 600 86400 300
@       IN  A   203.0.113.50
@       IN  A   203.0.113.51
img     IN  A   203.0.113.60  ; img.cdn.example.com
video   IN  A   203.0.113.70  ; video.cdn.example.com

Setting Up Delegation Without Creating a Lame Delegation

I've broken this badly enough times to know where the pitfalls are. A few years back, we onboarded a media client who delegated static.example.net to us but forgot to update the NS set in both places. Their parent zone advertised four name servers, but our side only configured two. For about half the resolvers on the internet, that looked like two dead servers — what we call a lame delegation. Resolution times doubled and we saw a 15% SERVFAIL rate for an hour until we synced the records. If you're going to use DNS delegation, consistency is everything.

The first thing to get right is glue records. If your delegation points to ns1.cdn.example.com — a hostname *inside* the zone you're delegating — resolvers need to know its IP address before they can find it. That's a chicken-and-egg problem, and glue in the parent zone solves it. But if your CDN uses out-of-zone names like ns1.cdn-provider.net, you don't need glue — the resolver can resolve that name through its normal path. Don't add unnecessary glue; it just creates another record to keep in sync and can cause validation issues if it drifts. The second thing is TTLs. Set your NS records TTL too long (say, 86400) and any future migration will be painful. We typically recommend 3600 seconds for NS sets, and 30-300 seconds for the actual A/AAAA records the CDN returns, since those are the ones that need to change quickly for failover or traffic steering.

You also have to think about security from day one. Once you delegate, the CDN provider is now authoritative for that zone, so DNSSEC has to be configured as a chain. You can't just sign the parent and forget the child. You'll need a DS record in the parent that matches the DNSKEY in the delegated zone on our edge. I always tell clients to test this with dig +trace +dnssec before going live. The pattern is well documented in the HTTP Working Group Specifications for related delegation behaviors, and if you're not careful, validation failures will make your delegated domain look bogus to every validating resolver. For a deeper look at getting this right without killing cache performance, see DNSSEC Signing for CDN Infrastructure: Authenticated DNS Without the Performance Hit.

# Verify your delegation is healthy - run this from outside your network
# 1. Check the parent returns the correct NS set
$ dig @a.gtld-servers.net cdn.example.com NS +norecurse

; ANSWER SECTION:
cdn.example.com.        3600    IN  NS  ns1.cdn-edge.net.
cdn.example.com.        3600    IN  NS  ns2.cdn-edge.net.

; ADDITIONAL SECTION (glue if needed):
ns1.cdn-edge.net.       3600    IN  A   192.0.2.10

# 2. Query the CDN's authoritative server directly
$ dig @ns1.cdn-edge.net img.cdn.example.com A +dnssec +short
203.0.113.60

# 3. Full trace to catch lame delegations or missing DS records
$ dig cdn.example.com +trace +dnssec
$ drill -T cdn.example.com

# 4. Check EDNS Client Subnet is being passed through correctly
$ dig @ns1.cdn-edge.net img.cdn.example.com +subnet=203.0.113.0/24 +short

The Performance Trade-Off: When Full Delegation Beats CNAME or Anycast Alone

So why not just stick with CNAMEs? Speed and scale. In my measurements across three different edge networks, a CNAME-based setup adds an extra lookup step — the resolver has to query your origin DNS first, get the CNAME, then query the CDN's DNS. That typically adds 15-40ms to cold resolution time, and it means your origin DNS still takes a hit for every new client's first visit. With NS delegation, the resolver is sent directly to the CDN's anycast DNS on the first referral. There's no middleman. When you're serving 50,000 requests per second, that round-trip saving adds up, and more importantly, your origin DNS query volume collapses.

The other advantage is control over domain resolution logic. Once the CDN owns the zone, we can do things you simply can't do through a CNAME alias. We can answer with different IPs based on the client's /24, return a shorter TTL during an incident to drain traffic faster, or integrate health checks so we don't hand out an edge node that's currently failing. Pair that with EDNS Client Subnet for CDN Geolocation: Routing Users to the Nearest Edge and the edge DNS can see the actual client subnet, not just the resolver's IP, so routing decisions are far more accurate. You don't get that level of per-query steering if you're just handing back a static CNAME target. The web.dev Articles on DNS performance consistently show how reducing resolution chains improves Largest Contentful Paint, and this is one of the most effective ways to shorten that chain.

It isn't free, though. Delegation means you're managing two separate DNS zones, and changes require coordination. If you need to revoke a delegation, you have to change the parent zone, which takes time to propagate due to NS caching at TLD servers and resolvers. CNAMEs are simpler to roll back. That's why I usually advise clients: if you have a low-traffic site or just need to accelerate a single hostname, a CNAME is fine. If you're running a high-traffic property, handling user-generated subdomains like *.user.cdn.example.com, or you need fine-grained traffic engineering, delegation is worth the operational overhead.

Putting NS Delegation Live: Zone Cuts, Glue, and Verification

You don't just flip a switch and delegate. The sequence matters, and getting it backwards is how you create a 2-hour outage that won't show up in your monitoring until users complain. First, you’ve got to provision the delegated zone on the CDN's authoritative platform before you publish the NS records in the parent. If you publish the cut first, resolvers following the delegation will hit NXDOMAIN or SERVFAIL for up to the negative cache TTL — typically 300 to 900 seconds — and you'll be chasing ghosts.

Here’s what a clean delegation looks like for cdn.example.com in your parent zone. We’re using four out-of-bailiwick nameservers (which is ideal — you avoid glue record maintenance entirely), with a conservative 86400s TTL on the NS set. Don’t set that TTL too low; we’ve seen teams use 300s “for flexibility” and then wonder why their TTFB jumped 15-25ms globally. Every resolver now has to re-query your parent’s TLD servers 288x more often. Keep the delegation TTL long and let the CDN handle low-TTL failover inside the delegated zone where it can respond in ~8-12ms from anycast edge.

; Parent zone: example.com (e.g., Route53, Cloudflare, BIND)
; 1. Create zone "cdn.example.com" on CDN provider FIRST
; 2. Then add delegation in parent:

$TTL 3600
cdn.example.com.  86400  IN  NS  ns1.edge.cdnprovider.net.
cdn.example.com.  86400  IN  NS  ns2.edge.cdnprovider.net.
cdn.example.com.  86400  IN  NS  ns3.edge.cdnprovider.net.
cdn.example.com.  86400  IN  NS  ns4.edge.cdnprovider.net.
; No glue (A/AAAA) needed - nameservers are out-of-bailiwick

; Verification - run these BEFORE updating registrar/parent:
; dig +trace cdn.example.com A
; dig @8.8.8.8 cdn.example.com NS +norecurse
; dig @ns1.edge.cdnprovider.net cdn.example.com SOA +norecurse

Once published, verify the delegation chain with dig +trace and DNSViz. You're looking for a clean zone cut with no lame delegation warnings. If you’re delegating a sub-subdomain like assets.cdn.example.com and your CDN’s nameservers live inside that same name (in-bailiwick), you’ll absolutely need glue A/AAAA records in the parent — miss those and 30-40% of resolvers will fail to follow the delegation. It’s the most common ticket we see from enterprise teams doing this the first time.

Advanced Patterns and Why Delegations Go Lame

Full NS delegation unlocks patterns you simply can’t do with a CNAME. The big one is apex-like control without violating the DNS spec. Need to serve different A records for cdn.example.com based on EDNS Client Subnet, ASN, or even real-time load? With delegation, your CDN’s authoritative fleet — usually 200+ anycast PoPs — can answer directly and run sophisticated traffic steering, geofencing, or DNS Sinkholing at CDN Scale: Redirecting Malicious Traffic for Analysis at the edge. You can’t sinkhole or do regional blackholing with a simple CNAME; you need authority.

That power also means you own a new failure domain. A lame delegation — where the parent points to nameservers that aren’t actually authoritative for the child — will give you intermittent SERVFAILs that are brutal to debug because they’re resolver-dependent. Google Public DNS might cache the failure for 5 minutes while Cloudflare 1.1.1.1 still serves stale data, so your synthetic checks look green. Always monitor from multiple vantage points. We run dig +dnssec checks every 30 seconds from 6 regions, and alert if more than 2% of queries return SERVFAIL or if delegation consistency checks fail. And don’t forget to harden that delegated zone — an NS-delegated zone is now a high-value target for reflection, so you’ll want DNS Amplification Attack Mitigation: Protecting CDN DNS Infrastructure enabled on the CDN’s DNS tier, not just your origin.

The other pattern worth calling out is automated failover inside the delegation. When your origin in us-east-1 goes dark, you don’t want to wait for a human to change DNS. With NS delegation, the CDN can run health checks every 10-15 seconds and flip the delegated zone’s A records in under 20 seconds, with a 30s TTL inside the zone. That’s how you get true DNS Failover Automation for CDN: Automatic Rerouting When Origins Go Down without touching the parent zone at all. We’ve cut failover time from 3-4 minutes (CNAME + parent TTL propagation) to 35-45 seconds end-to-end this way — and you keep full query logs and analytics on the CDN side to prove it.

Frequently Asked Questions