CDN DNS Migration Planning: Changing DNS Providers Without Breaking Resolution

I'll never forget watching a retail client's error rate flatline to 100% at 2:17 AM because someone flipped the NS records before the new DNS provider had the full zone loaded. The CDN itself was healthy, the origins were fine, but resolvers simply couldn't find them. We spent the next four hours waiting out cached NS records we couldn't purge, and that night taught me you don't just change DNS providers — you choreograph a handoff where resolution continuity is non-negotiable.

The Hidden Dependencies That Make CDN DNS Changes Risky

When you're running traffic through a CDN, DNS isn't just a phone book, it's the steering wheel. Most CDN setups rely on a CNAME chain or delegated subdomains like cdn.example.com that point to the provider's Anycast edge, and that chain often includes alias records, load balancing logic, and geographic routing rules that don't exist in a standard BIND file. I've seen teams treat a CDN DNS change like swapping any other SaaS provider, only to discover their new authoritative servers weren't answering the _acme-challenge records for certificate renewal or the edge health checks the CDN uses to steer traffic. If you've mapped your current architecture against a Comprehensive CDN Migration Checklist: Every Step from Planning to Cutover, you know how many of those records are undocumented until they break.

Resolution continuity fails for boring reasons, not exotic ones. Old NS records live in resolver caches long after you've changed them at the registrar, negative caching hides missing records, and some ISP resolvers ignore your TTL entirely and hold onto data for hours. During one migration for a media company pushing 800 Gbps, we had 94% of queries hitting the new provider within 20 minutes, but a single regional ISP in Brazil kept serving the old delegation for six hours because they'd hard-coded a 24-hour minimum TTL. The CDN kept serving stale content to that region until we manually re-added the old zone. That's why a DNS migration plan has to assume both providers will be queried in parallel for at least 48 hours, and why your DNS switchover isn't complete when you change the delegation — it's complete when the last cached record expires.

#!/bin/bash
# compare authoritative vs. recursive resolution before cutover
DOMAINS=("www.example.com" "cdn.example.com" "api.example.com")
OLD_NS="ns1.old-provider.net"
NEW_NS="ns1.new-provider.net"

for domain in "${DOMAINS[@]}"; do
  echo "=== $domain ==="
  echo -n "OLD: "; dig +short @$OLD_NS $domain A | head -1
  echo -n "NEW: "; dig +short @$NEW_NS $domain A | head -1
  echo -n "PUBLIC (8.8.8.8): "; dig +short @8.8.8.8 $domain A | head -1
  echo -n "PUBLIC (1.1.1.1): "; dig +short @1.1.1.1 $domain A | head -1
  echo ""
done

# Check SOA serials match - they MUST be in sync
echo "SOA Serial Check:"
dig +short @$OLD_NS example.com SOA | awk '{print "OLD SOA:", $3}'
dig +short @$NEW_NS example.com SOA | awk '{print "NEW SOA:", $3}'

Building Parity Before You Touch the Delegation

The least glamorous part of a CDN DNS change is also the most important: making the new provider an exact mirror before anyone on the internet knows it exists. I start this work at least a week out, and the first move is always lowering TTLs. If your apex is sitting at 86400 seconds, drop it to 300 seconds 72 hours before migration, and do the same for any CNAMEs the CDN depends on. Yes, you'll increase query volume and your bill might tick up slightly, but that low TTL is your only escape hatch if you need to roll back. I learned this the hard way in 2019 when we tried to revert a failed migration with a 4-hour TTL — we were stuck watching 4 hours of SERVFAILs roll in. Don't skip this step, even if your product manager is pushing for a faster timeline.

Once TTLs are low, export the full zone from your current provider — including all the records you think you don't need — and import it into the new one, then verify parity byte-for-byte. Pay special attention to DNSSEC chains, ANAME/ALIAS records at the apex, and any provider-specific records like Cloudflare's proxied flags or Route 53 alias targets that won't translate one-to-one. You'll also want to confirm how the new provider handles EDNS Client Subnet and CNAME flattening, because two providers can both return "correct" answers that steer CDN traffic differently. We run automated comparisons for at least 48 hours in what I call shadow mode, where both sets of nameservers are authoritative but only the old one is delegated. If you're selecting a new provider right now, a rigorous CDN Vendor Evaluation Matrix: Scoring Providers on What Actually Matters should have already forced you to validate these edge behaviors, and your CDN RFP Template: Writing Requirements That Get Meaningful Vendor Responses should have documented them as requirements, not assumptions.

# Python: fail the build if zone records diverge
import dns.resolver
import dns.zone
from collections import Counter

OLD_NS = "ns1.old-provider.net"
NEW_NS = "ns1.new-provider.net"
ZONE = "example.com"
RECORD_TYPES = ["A", "AAAA", "CNAME", "TXT", "MX", "CAA"]

def get_records(ns, name, rdtype):
    resolver = dns.resolver.Resolver()
    resolver.nameservers = [OLD_NS if ns == OLD_NS else NEW_NS]
    try:
        answers = resolver.resolve(name, rdtype)
        return sorted([r.to_text() for r in answers])
    except Exception as e:
        return [f"ERROR: {e}"]

mismatch = False
for rdtype in RECORD_TYPES:
    old = get_records(OLD_NS, ZONE, rdtype)
    new = get_records(NEW_NS, ZONE, rdtype)
    if Counter(old) != Counter(new):
        print(f"[MISMATCH] {ZONE} {rdtype}")
        print(f"  OLD -> {old}")
        print(f"  NEW -> {new}")
        mismatch = True

if mismatch:
    raise SystemExit("Zone parity check failed - do not cut over")
else:
    print("All checked records in sync")

Executing the Cutover Without Losing a Query

With parity confirmed, the actual DNS switchover is anti-climactic if you've done the prep right. Don't do a hard flip of all NS records at once. Instead, update the delegation at your registrar to include nameservers from both providers for 24 to 48 hours — most TLDs allow up to 13 NS records, so you can run 2 old + 2 new concurrently. This dual-delegation period means resolvers will query whichever provider responds fastest, and if the new one has an issue, traffic naturally falls back without you touching anything. Only after your monitoring shows stable resolution from the new provider do you remove the old NS records. It feels slower, but I've never had a dual-delegation cutover cause an outage; I've had several single-flip cutovers cause one.

During that window, you're watching two things obsessively: authoritative query volume on both providers and recursive resolution success from the outside. Your new provider's dashboard should show query share climbing from 0% to roughly 50% within an hour and to 90%+ within the old TTL window. At the same time, you should be running synthetic checks from RIPE Atlas, Catchpoint, or even simple cron jobs on VMs in different networks that query public resolvers every 30 seconds. If you see SERVFAILs or inconsistent answers between 8.8.8.8, 1.1.1.1, and 9.9.9.9, pause and investigate before you remove the old delegation. The HTTP Working Group Specifications (https://httpwg.org/specs/) and web.dev Articles (https://web.dev/articles/) both emphasize that CDN performance is bounded by DNS reliability, and a 0.5% resolution failure rate will dwarf any cache hit ratio optimization you've done.

Keep your old provider's zone active and unmodified for at least seven days after you think you're done. I've seen teams delete the old zone on day two to save costs, then discover a forgotten internal tool was hardcoded to query the old nameserver IP directly. Set a calendar reminder, keep paying for those two extra days, and define a clear rollback trigger: if error rates exceed your baseline by more than 0.1% or if any synthetic monitor fails for five consecutive minutes, revert the delegation. Having that decision made before you're tired and stressed is what keeps a DNS migration boring — and boring is exactly what you want.

#!/bin/bash
# compare-dns-parity.sh - Validate resolution parity across providers
# Run every 60s from 3+ regions for 72h post-cutover

DOMAINS=("www.example.com" "cdn.example.com" "api.example.com")
OLD_NS="ns1.old-provider.net"
NEW_NS="ns1.new-provider.net"
LOG="dns-parity-$(date +%F).log"

for domain in "${DOMAINS[@]}"; do
  for qtype in A AAAA CNAME TXT; do
    old_resp=$(dig @$OLD_NS $domain $qtype +short +tries=2 | sort)
    new_resp=$(dig @$NEW_NS $domain $qtype +short +tries=2 | sort)
    
    # Compare TTLs and answers explicitly
    old_ttl=$(dig @$OLD_NS $domain $qtype +noall +answer | awk '{print $2}' | head -1)
    new_ttl=$(dig @$NEW_NS $domain $qtype +noall +answer | awk '{print $2}' | head -1)

    if [[ "$old_resp" != "$new_resp" ]] || [[ "$old_ttl" != "$new_ttl" ]]; then
      echo "[MISMATCH] $domain $qtype | OLD:'$old_resp' (TTL $old_ttl) NEW:'$new_resp' (TTL $new_ttl)" | tee -a $LOG
    else
      echo "[OK] $domain $qtype | TTL $new_ttl" | tee -a $LOG
    fi
  done
done

# Also check delegation from parent - critical!
echo "--- Parent delegation check ---"
dig +trace +nodnssec www.example.com | grep -E "NS|Received"