The moves nobody tells you about
Most guides stop at updating your registrar's nameserver fields and waiting for propagation. That works for a static brochure site. For anything handling real traffic—SaaS platforms, e-commerce, multi-region apps—you need to think about DNSSEC key continuity, resolver cache behavior, and the thirty-second window when half the internet points to old infrastructure and half to new.
I've handled enough migrations gone wrong to know the pattern: someone changes nameservers Friday afternoon, email stops working Monday morning, and the root cause is a missing glue record or a DNSSEC chain that broke because nobody coordinated KSK rollovers between the old and new providers. The fixes below assume you already know how to change nameserver records at your registrar. We're going deeper.
1. Pre-lower TTLs a full cycle before cutover
Everyone talks about lowering TTL values before a nameserver change, but most do it wrong. Dropping your SOA and NS record TTLs to 300 seconds ten minutes before the switch does nothing—resolvers that cached the old 86400-second TTL yesterday will ignore your new short value until tomorrow.
The move: identify your current TTL for NS records (usually inherited from the zone's SOA if not set explicitly). At least twice that duration before your planned cutover, lower the TTL to five minutes. If your NS TTL is 24 hours, make the change 48 hours early. Now when you update nameservers at the registrar, most resolvers will have the short TTL cached and will refresh quickly.
After the migration stabilizes, raise TTLs back to something sane—3600 to 7200 seconds for NS records is typical. Leaving them at 300 forever just creates unnecessary query load.
# Check current NS TTL
dig +noall +answer NS example.com
# You'll see something like:
# example.com. 86400 IN NS ns1.oldprovider.com.
That 86400 is your enemy during a migration.
2. Coordinate DNSSEC key timing between old and new providers
If your zone is signed, a naive nameserver change will break validation for every resolver that supports DNSSEC. The new nameservers serve records signed with keys the parent zone doesn't know about yet, so validators see a broken chain of trust and return SERVFAIL.
The right sequence: get the new provider's DS records (the hash of their zone-signing keys) and add them to your registrar before you change nameservers. Most registrars let you have multiple DS records active at once. Leave both old and new DS records in place for at least the TTL of the parent zone's DS record (often 24-48 hours). Only after that window do you change the NS records. Finally, a day or two after the NS change, remove the old provider's DS records.
This keeps the chain of trust intact through the entire migration. Validators can verify signatures from either the old or new nameservers during the overlap.
# Get DS records from new provider (they'll give you these)
# Example format:
example.com. IN DS 12345 13 2 A1B2C3D4...
# Add to registrar alongside existing DS records
# Wait for parent TTL to expire (check with dig DS example.com)
# Then change NS records
# Wait another cycle, then remove old DS records
Skip this and you'll see intermittent resolution failures that only affect a fraction of users—the ones behind validating resolvers.
3. Set up a hidden primary if you're moving to Anycast
Many high-performance DNS providers use an Anycast model: the same nameserver IPs are announced from multiple global locations, and the network routes you to the nearest one. Great for latency. But if you're generating dynamic DNS updates or running automated Let's Encrypt validations that expect to push updates via AXFR or UPDATE messages, Anycast nameservers often don't accept inbound zone transfers for security and consistency reasons.
The fix is a hidden primary (also called a stealth primary): your own authoritative server that holds the master zone file and pushes changes out to the Anycast secondaries via NOTIFY and AXFR. The hidden primary's IP doesn't appear in public NS records, so it never answers public queries. Your automation points updates at the hidden primary, which then syncs to the provider's network.
Most Anycast DNS services document this setup. You'll configure your hidden primary (BIND, PowerDNS, Knot, whatever you prefer) with the provider's transfer IPs in allow-transfer and their networks in also-notify. On the provider's side, you register your hidden primary's IP so their infrastructure knows to pull zones from it.
# BIND named.conf snippet for hidden primary
zone "example.com" {
type master;
file "/var/named/example.com.zone";
allow-transfer { 203.0.113.10; 203.0.113.11; }; # provider's transfer IPs
also-notify { 203.0.113.10; 203.0.113.11; };
notify yes;
};
Without this, you lose the ability to programmatically update DNS, which breaks ACME DNS-01 challenges, dynamic service discovery, and anything else that expects mutable zones.
4. Audit and recreate glue records at the registrar
Glue records solve a bootstrapping problem: if your nameservers are ns1.example.com and ns2.example.com, a resolver trying to look up example.com needs to ask those nameservers for their own A records. But it can't find the nameservers without already knowing their IPs. Glue records are A (or AAAA) records stored at the registrar alongside your NS records, breaking the circular dependency.
When you change nameservers, check whether the new servers are under the same domain you're delegating. If you're moving from ns1.example.com to ns1.newprovider.com, you probably don't need glue anymore (the resolver can find ns1.newprovider.com independently). But if you're moving to ns1.example.com under a new IP, you must update the glue records at the registrar or the zone will be unreachable.
Most registrar control panels hide this in an "advanced" or "nameserver IP" section. Some registrars auto-populate glue when you enter in-domain nameservers; others require manual entry. Verify it's correct after the change.
# Check current glue records from parent zone
dig +trace example.com | grep -A2 'Received.*from.*parent'
# You should see A records for your nameservers alongside NS records
Missing or stale glue records are silent killers. A small fraction of resolvers will query the parent's authoritative servers directly and hit the problem, while others use cached referrals and work fine. Debugging this feels like intermittent ghosts.
5. Test resolution from multiple vantage points before flipping
Before you change nameservers at the registrar, make sure the new nameservers actually respond correctly. Sounds obvious, but I've seen migrations where the new provider hadn't finished provisioning the zone, or where the transferred zone was missing critical records because the export-import process mangled them.
Query the new nameservers directly by IP before they're live:
# Query the new nameserver directly (replace with actual new NS IP)
dig @203.0.113.5 example.com ANY
dig @203.0.113.5 www.example.com A
dig @203.0.113.5 example.com MX
Check every record type you care about: A, AAAA, MX, TXT, CNAME. Compare the responses to what the old nameservers return. Look for missing records, wrong TTLs, or formatting issues (especially in TXT records for SPF/DKIM/DMARC, where line breaks and quoting can break).
Use a tool like DNSViz or Zonemaster to validate DNSSEC before and after if you're running signed zones. Catching a broken signature in testing is easier than explaining downtime to customers.
6. Parallelize queries to old and new resolvers during the soak period
For services where DNS accuracy is critical—think SaaS platforms where customers point CNAMEs at you—consider running both old and new nameservers in parallel for a soak period before fully cutting over. This isn't always possible (it depends on whether your DNS provider supports multi-master setups or whether you control the primary), but when you can do it, it's powerful.
The idea: keep the old NS records active at the registrar, but add the new ones too. Most zones can have multiple NS records pointing to different providers. Resolvers will try them in random order or based on response time. If the new provider has issues, a fraction of queries fail over to the old infrastructure.
After a few days, check query logs or monitoring to confirm the new nameservers are handling traffic correctly. Then remove the old NS records. This staged approach limits blast radius if something was misconfigured.
Not every registrar or DNS provider supports this cleanly (some panic if you list NS records from two different providers), so test in a staging domain first if you're unsure.
7. Monitor query response time and NXDOMAIN rates post-migration
Performance can regress after a nameserver change even if resolution technically works. Maybe the new provider's Anycast network doesn't have a PoP near your heaviest user base. Maybe their authoritative servers are tuned for small zones and yours is large enough to cause slow AXFR transfers and stale secondaries.
Set up monitoring that tracks:
- Median and p95 DNS resolution time from multiple geographic locations
- Rate of NXDOMAIN responses (shouldn't spike unless you lost records during migration)
- Query volume to each nameserver if the provider gives you stats
A small increase in resolution time might not matter for a blog, but it absolutely matters for API-heavy applications where every request triggers a DNS lookup. If you see problems, check whether your new provider offers options like additional secondaries in specific regions or tuning for large zones.
# Quick test for response time from a specific location
for i in {1..10}; do
dig @ns1.newprovider.com example.com +stats | grep 'Query time'
done
That gives you a rough p50/p90 from your location. For production, use a real monitoring service with global probes.
8. Automate rollback with pre-staged registrar API calls
If your registrar has an API (most do now), script the rollback before you migrate. Save a script or Terraform config that reverts NS records to the old values. When something breaks at 2 a.m. and you're half-awake, you don't want to fumble through a web UI trying to remember the old nameserver hostnames.
Store the rollback script somewhere the on-call team can access it. Include the old NS records, old DS records if you're using DNSSEC, and any glue records that need to be re-added. Test the script in a dev domain so you know it works.
#!/usr/bin/env python3
# Example rollback script (pseudo-code, adapt to your registrar's API)
import registrar_api
api = registrar_api.Client(api_key='YOUR_KEY')
api.update_nameservers(
domain='example.com',
nameservers=['ns1.oldprovider.com', 'ns2.oldprovider.com']
)
print("Rolled back nameservers to old provider")
You might never use it. But knowing you can revert in sixty seconds instead of thirty minutes turns a potential catastrophe into a controlled step backward.
What about service-specific DNS optimizations?
If you're running services that depend on DNS beyond basic resolution—GeoDNS for CDN routing, split-horizon DNS for internal vs. external views, DNS-based load balancing—test those features explicitly after the migration. Providers implement these differently. What worked as a weighted A record on one platform might require a completely different record type or API call on another.
For GeoDNS especially, verify that the geographic mappings actually route traffic correctly. Spin up a VPS in a target region, query your domain, and confirm you get the expected IP. Don't assume the new provider's geo database matches the old one.
Frequently asked questions
How long does it take for a nameserver change to fully propagate?
The parent zone's NS TTL governs this. Typically 24-48 hours for complete propagation, but if you pre-lowered TTLs correctly, most resolvers will pick up the change in under an hour.
Can I change nameservers and DNS records at the same time?
Risky. Change nameservers first, wait for propagation, then modify records. Doing both at once makes it impossible to tell which change caused a problem if something breaks.
What if I don't have access to the old provider anymore?
You can still migrate, but you lose the ability to coordinate a clean cutover. Set up the new zone from scratch, double-check every record, and accept that there will be a hard cutover moment with no overlap. Pre-lower TTLs as much as possible before the old provider disappears.
Do I need to notify users before changing nameservers?
For most setups, no—if done correctly, users see no downtime. For large infrastructures where customers point CNAMEs or NS delegations at you, give advance notice so they can update monitoring and runbooks.
Check these before you commit the change
Nameserver migrations fail when you treat them like a single atomic action. They're a multi-step process with timing dependencies. Lower TTLs early. Coordinate DNSSEC carefully. Audit glue records. Test the new nameservers before making them live. Monitor after the change. Have a rollback plan ready.
The difference between a smooth migration and a weekend firefighting DNS outages usually comes down to two or three of these steps that seemed optional until they weren't. Run through this list, and you'll avoid most of the ways these changes go wrong.