Blog

Most DNS outages don’t start with an attack or a hardware failure. They start with a change: two digits swapped in an IP address, a record deleted because nobody remembered what used it, a nameserver switch made at 4:45 on a Friday.

DNS makes those mistakes unusually expensive, because you can’t take an answer back once it’s been handed out. Every resolver that cached the old (or broken) record keeps serving it until its TTL runs out, however quickly you fix things on your end. The good news is that almost any DNS change can be made safely with a little planning. Here’s the process we recommend after more than 25 years of running authoritative DNS, including the parts that usually get skipped.

Why DNS changes don’t really “propagate”

You’ll often hear that DNS changes take 24 to 48 hours to propagate. That isn’t quite what happens. When you save a record, your authoritative nameservers start serving the new answer almost immediately, and nothing gets pushed out to the rest of the internet after that. What takes time is caching.

Recursive resolvers (the DNS servers run by ISPs, companies and public services such as Google Public DNS) keep every answer they receive for as long as the record’s TTL, or time to live, allows. A record with a TTL of 86400 seconds can be served from a cache for up to 24 hours after you’ve changed it. Each resolver cached the record at a different moment, so each copy expires at a different moment. That’s why a change appears to spread gradually.

Here’s the detail that catches people out: the TTL that matters is the one resolvers saw before your change, not the one you set during it. Lowering a TTL from 86400 to 300 and changing the IP address five minutes later doesn’t help. Every resolver that cached the record during the previous day is still holding the 24-hour version.

Record TTLs aren’t the only clocks running, either. These are the caches that decide how long an old answer can linger:

A few resolvers also bend the rules. Some enforce a minimum TTL and many cap very long ones, so plan for the occasional straggler rather than assuming every cache expires on schedule.

Before you change anything

Ten minutes of preparation prevents most of the problems we see. For anything beyond a routine edit, work through these steps first.

Making the change

Change one thing at a time. If you’re moving a website, switching email providers and turning on DNSSEC, make those three separate changes with time to verify in between. When something breaks after a combined change, you won’t know which part to undo.

Beyond that, the same handful of mistakes come up again and again:

Keep the old destination running. When you move a site or service to a new IP address, leave the old server up (serving the same content, or redirecting to the new one) until well after the old TTL has passed. Some resolvers, devices and long-lived connections will keep using the old address for a while, and a working old server turns that from an outage into a non-event.

Verify from the source outward

Your own computer is the worst place to check a DNS change, because it’s sitting behind at least two caches. Check in this order: your authoritative nameservers first, then public resolvers, then the service itself.

# Ask every authoritative nameserver directly (no caches involved)
for ns in $(dig +short NS example.com); do
  echo "$ns $(dig +short @$ns www.example.com A +norecurse)"
done

# Windows PowerShell: the same check, one nameserver at a time
Resolve-DnsName www.example.com -Server ns1.example.net -NoRecursion

# Every nameserver should report the same SOA serial
for ns in $(dig +short NS example.com); do
  echo "$ns $(dig +short @$ns example.com SOA +norecurse | awk '{print $3}')"
done

# What a public resolver has cached, and how many seconds it has left
dig @8.8.8.8 www.example.com A +noall +answer

# Test a website on its new IP before DNS points there
curl -sI --resolve www.example.com:443:203.0.113.10 https://www.example.com/

No terminal handy? Our free Support Utilities include a DNS lookup that can query a specific nameserver and a propagation check that polls public resolvers for A records.

What to expect: your authoritative nameservers should show the new answer right away, and all of them should agree. Public resolvers may keep showing the old answer until the TTL in that dig output counts down to zero. That’s normal, not a failed change.

Finally, test the thing you actually changed. Load the website. Send a message to an outside mailbox and check its headers for SPF, DKIM and DMARC passes. If you touched CAA or _acme-challenge records, confirm that certificate renewal still works.

After the change

• Watch it for a while. Keep an eye on your monitoring, the old server’s logs (traffic there should taper off as caches expire) and your mail logs. Checks that run from outside your network will spot problems your own caches hide.
• Put the TTL back. Once you’re confident the change is good, raise the TTL to its normal value. Permanently low TTLs mean more queries, slower lookups for your visitors and less protection if your nameservers are ever unreachable, because cached answers keep working when nothing else does. Records behind DNS failover are the exception: their short TTL is what lets a failover take effect quickly.
• Retire the old destination, and its records. Shut down the old server only once the old TTL has long passed. When you decommission anything (a cloud instance, a storage bucket, a SaaS account), remove the DNS records that point at it first, then release the resource. A CNAME left pointing at something you no longer control is how subdomain takeovers happen.

Changes that deserve extra care

Most records are forgiving. These aren’t.

Moving to a new DNS provider

Nameserver changes have the longest tail of any DNS change, because the delegation lives in the TLD’s zone rather than yours. For .com and .net, those records carry a 48-hour TTL that you can’t shorten, so some resolvers will keep asking your old provider for two days or more after you switch.

1. Recreate the zone at the new provider exactly: every record, not just the ones you remember. Importing a zone file, or setting the new provider up as a secondary so it pulls a copy by zone transfer (if your current provider allows it), beats retyping.
2. Query the new provider’s nameservers directly, using the same dig @nameserver checks shown above, and compare their answers with the old provider’s for every important name.
3. If the zone is signed with DNSSEC, deal with that first (see below).
4. Change the nameservers at your registrar.
5. Keep the old provider running with identical records for at least a few days; we suggest a week. If you must change a record during the overlap, change it at both providers.
6. Then cancel the old service.

DNSSEC

DNSSEC mistakes are the least forgiving kind. When a zone is signed, the TLD holds a DS record that tells validating resolvers which key to expect. If that DS record and the keys your nameservers publish stop matching, validating resolvers (including the big public ones) return SERVFAIL and your domain disappears for their users. The registry sets the DS record’s TTL, 24 hours for .com, so a mistake can take a day to clear however fast you fix it.

• Turning DNSSEC on: sign the zone, confirm the signatures validate, and only then add the DS record at your registrar.
• Turning it off, or moving to a provider that will sign with new keys: remove the DS record first, wait at least the DS TTL (two days is a safe margin), then stop signing or make the move.
• Changing keys: follow your provider’s rollover procedure and don’t shortcut the waiting periods. They exist because of caches.
• Checking your work: run the zone through a validating tool such as DNSViz or delv after every step, before you move on to the next.

Running DNSSEC across two providers at once takes careful key handling, so talk to us before you set it up.

Email records: MX, SPF, DKIM and DMARC

Email problems caused by DNS changes tend to be quiet. Messages bounce or drift into spam folders, and nobody notices for days.

• MX: sending servers keep retrying for days if your mail server is briefly unreachable, but an MX that points at a hostname that doesn’t exist often causes immediate bounces. When you move mail providers, set up the new service first and keep the old one receiving until the old MX TTL has passed.
• SPF: publish exactly one v=spf1 record per name, add a new sending service before you start using it, and stay under the 10-DNS-lookup limit. Every include: counts, and so do the includes nested inside it.
• DKIM: publish the new selector before the new service starts signing, and leave the old selector in place for a while after you stop using it, since mail already in transit was signed with it.
• DMARC: tighten the policy in stages (p=none, then quarantine, then reject) and read the aggregate reports at each stage. Jumping straight to p=reject is how legitimate mail from a forgotten sender ends up rejected.

CAA and certificate records

A CAA record limits which certificate authorities can issue certificates for your domain. Add one without listing the CA you actually use and your next renewal will fail, often weeks later, when nobody connects it to the change. Leave _acme-challenge records (and any CNAMEs that delegate them) alone unless you know what renews certificates through them.

Wildcard records

A wildcard such as *.example.com answers for every name that doesn’t otherwise exist. Adding one can make typos look like working hostnames, and removing one can break services that quietly depended on it, so check what relies on a wildcard before you add or remove one.

Guardrails worth putting in place

Good habits for individual changes go further with a little structure around them.

A checklist you can reuse

Copy this into your runbook, or keep it next to the screen the next time you make a change.

Frequently asked questions

How long does a DNS change take to take effect?

Your authoritative nameservers serve it almost immediately. The rest of the internet catches up as cached copies expire, which takes up to the TTL the record had before the change. Nameserver changes for .com and .net domains can take up to 48 hours because of the TLD’s own TTL.

What TTL should I use?

For records that rarely change, an hour to a day is reasonable. Drop to around 300 seconds ahead of a planned change and raise it again afterwards. Records behind DNS failover are the exception, since a short TTL is what makes failover fast.

Can I make a DNS change take effect faster?

Not after the fact; you can’t recall answers that are already cached. You can ask Google Public DNS and Cloudflare to drop their copies and flush your own computer’s cache, but every other resolver will wait out the TTL. The only reliable way to make a change fast is to lower the TTL well before you make it.