Why Is My Domain Not Resolving After a DNS Change?

You changed a DNS record or moved your domain to a new provider, and now the site won't load — or it loads for you but not for a client, or it works on mobile data but not on the office network. The standard advice is "wait for propagation," and sometimes that's right. But a lot of the time, waiting won't help, because the change itself broke something that no amount of time will fix. The post on DNS propagation delay explains the normal timing; this article is about telling normal caching apart from a genuine fault, and finding the fault fast.

We'll walk through a diagnostic sequence that starts at the authoritative source and works outward, then cover the specific failure modes that show up after record edits, nameserver changes, and provider migrations — including the DNSSEC mistake that takes entire domains offline.

First, Classify the Symptom

Before running any commands, pin down what "not resolving" actually looks like, because each symptom points in a different direction:

Symptom	Most likely cause
Old IP or old site still appears	Cached record (positive TTL) — usually just time
Works for some people, not others	Different resolvers holding different cached data
NXDOMAIN everywhere	Record missing on the new provider, or broken delegation
NXDOMAIN only for you, right after creating a record	Negative caching of an earlier lookup
SERVFAIL everywhere	DNSSEC validation failure or lame delegation
Times out everywhere	Nameservers unreachable or not serving the zone

The rule of thumb: an old answer is usually caching, while no answer, an error, or a failure everywhere is usually configuration. To tell which you have, you need to compare what the authoritative servers say with what resolvers are returning.

Step 1: Ask the Authoritative Servers Directly

Resolvers can be stale. Authoritative nameservers can't be — they are the source. So the first question is: do the authoritative servers actually have the record you expect?

Find out which nameservers the world currently uses for your domain, then query one directly with recursion turned off:

# Which nameservers does the parent zone delegate to?
dig example.com NS +short

# Ask one of them directly, without recursion
dig @ns1.example-dns-host.net www.example.com A +norecurse

In the second response, look for the aa (authoritative answer) flag in the header and the record in the answer section. If the authoritative server returns the new value, your change is live at the source and anything else you see is caching. If it returns the old value, an error, or nothing, your change isn't where you think it is — keep reading.

Step 2: Check What the Parent Zone Delegates To

After a nameserver change, the record that matters lives one level up — in the TLD zone, not your own. Ask a TLD server directly which nameservers it hands out:

# For .com and .net domains
dig @a.gtld-servers.net example.com NS +norecurse

# For other TLDs, look up the TLD's servers and ask the first one
dig @"$(dig org NS +short | head -n 1)" example.org NS +norecurse

The TLD server's response lists the delegated nameservers in the authority section. Compare that list with the nameservers your new provider told you to use. If the TLD still lists the old provider's servers, the nameserver update at the registrar didn't go through (or hasn't been processed yet). If it lists the new ones, delegation is correct.

Keep in mind that these delegation NS records carry their own TTL — for .com and .net it's 172,800 seconds (two days). Resolvers that cached the old delegation may keep sending queries to the old provider for up to that long, which is why nameserver changes take longer to settle than record edits. If you're not sure which company controls which part of this chain, see the difference between a domain registrar and a DNS host.

Step 3: Make Sure Every Nameserver Agrees

A domain typically has two to four nameservers, and resolvers pick between them. If one of them has stale or missing data, you'll see intermittent failures that look random. The +nssearch option queries every listed nameserver for the zone's SOA record:

dig example.com +nssearch

Each line of output shows a nameserver's SOA serial number and response time. All serials should match. A server with a lower serial hasn't picked up the latest zone version (often a secondary that failed a zone transfer), and a server that doesn't respond at all is a lame delegation — listed at the parent but not actually serving your zone.

If you want to check the record itself across every nameserver, this Python script with dnspython does it:

import dns.exception
import dns.flags
import dns.message
import dns.query
import dns.rcode
import dns.resolver

ZONE = "example.com"
NAME = "www.example.com"
RTYPE = "A"

for ns in dns.resolver.resolve(ZONE, "NS"):
    ns_host = ns.target.to_text()
    ns_ip = dns.resolver.resolve(ns_host, "A")[0].address
    query = dns.message.make_query(NAME, RTYPE)
    query.flags &= ~dns.flags.RD  # no recursion: ask for authoritative data only
    try:
        response = dns.query.udp(query, ns_ip, timeout=3)
        rcode = dns.rcode.to_text(response.rcode())
        values = [rr.to_text() for rrset in response.answer for rr in rrset]
        print(f"{ns_host:<32} {rcode:<9} {', '.join(values) or '(empty)'}")
    except dns.exception.Timeout:
        print(f"{ns_host:<32} TIMEOUT")

The script resolves the zone's NS set, looks up each nameserver's IPv4 address, and sends a non-recursive query to each one, printing the response code and returned values. Any nameserver that disagrees with the others is where to focus.

Step 4: Compare Public Resolvers

Once the authoritative side is confirmed, check what the big public resolvers are returning:

for r in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
  printf "%-16s " "$r"
  dig @"$r" www.example.com A +short | tr '\n' ' '
  echo
done

This prints each resolver's answer on one line. If authoritative servers have the new value and some resolvers still return the old one, that's ordinary caching and it will clear within the record's previous TTL. The full set of tools for this stage, including global checkers, is covered in how to check if DNS changes have propagated.

The Failure Modes That Waiting Won't Fix

If Steps 1–3 turned up a problem, it's almost certainly one of these.

1. You edited records at the wrong provider

This is the most common cause of "I changed it but nothing happened." Your domain's nameservers point to provider B, but you edited records in provider A's dashboard — often the registrar's default DNS panel, still showing the old zone. The change is real, it's just not served to anyone. Step 2 tells you which provider actually serves the zone; make your edits there.

2. You switched nameservers before building the zone

When you change nameservers at the registrar, the new provider must already have a complete copy of your zone. If it doesn't, the instant resolvers follow the new delegation they get REFUSED, SERVFAIL, or NXDOMAIN for every name. Recreate every record — A, AAAA, CNAME, MX, TXT, and anything else — at the new provider, verify with direct queries as in Step 1, and only then switch. Planning a zero-downtime DNS migration covers this ordering in full.

3. A stale DNSSEC DS record

If your domain had DNSSEC enabled at the old provider, the TLD zone contains a DS record that matches the old provider's signing key. When you move to a new provider that signs with different keys (or doesn't sign at all), validating resolvers see a chain of trust that no longer matches and return SERVFAIL. Every major public resolver and many ISP resolvers validate DNSSEC, so this looks like a partial outage that never clears: users behind validating resolvers fail, everyone else is fine.

Check whether a DS record exists and whether validation is failing:

# Is there a DS record at the parent?
dig example.com DS +short

# Does a validating resolver fail while a non-validating query succeeds?
dig @1.1.1.1 example.com A
dig @1.1.1.1 example.com A +cd

The +cd (checking disabled) flag tells the resolver to skip DNSSEC validation. If the normal query returns SERVFAIL and the +cd query returns the correct answer, DNSSEC is the problem. Remove the DS record at your registrar (or replace it with the new provider's DS), and the domain recovers once the old DS record's TTL expires. The safe way to move a signed domain is explained in what DNSSEC is and whether to enable it.

4. Missing or broken glue records

If your nameservers are inside your own domain — for example ns1.example.com serving example.com — the parent zone needs glue records containing their IP addresses. Change those servers' IPs without updating the glue at the registrar and resolvers can't reach your nameservers at all. A direct query to a TLD server shows the glue in the additional section:

dig @a.gtld-servers.net example.com NS +norecurse

If the IPs in the additional section are outdated, update the registered host (glue) records at your registrar.

5. Zone file syntax mistakes

Records entered in a raw zone file are easy to get subtly wrong. The classic error is a missing trailing dot:

; Wrong: no trailing dot, so the zone origin is appended
www   IN  CNAME  app.example-host.net
; Resolves as app.example-host.net.example.com. — which doesn't exist

; Right: the trailing dot marks a fully qualified name
www   IN  CNAME  app.example-host.net.

Other common slips include a CNAME at a name that also has other records (CNAMEs must stand alone), forgetting to bump the SOA serial so secondaries never transfer the change, and typos in the record name. If you run BIND, validate before reloading:

named-checkzone example.com /etc/bind/zones/db.example.com

named-checkzone parses the zone file and reports syntax errors, out-of-zone data, and CNAME conflicts before they reach production.

6. A negative answer got cached

If you or a colleague looked up a hostname before it existed — say, testing staging.example.com before creating the record — resolvers cached that NXDOMAIN. That negative answer persists for the zone's negative TTL regardless of what you do afterward. Check the value with dig example.com SOA +short (it's the last number, capped by the SOA record's own TTL). Negative caching explains the mechanics. This one genuinely does fix itself with time.

The Caching Cases (Where Waiting Is the Answer)

If the authoritative servers return the right data and the delegation is correct, what remains is caching at some layer:

1. Recursive resolvers keep the old record until its old TTL runs out. If the record had a TTL of 86400 before you changed it, some resolvers can serve the old value for a day. Lowering the TTL after the change doesn't help — resolvers already cached the old TTL. Lower it a day or two before the change next time; the post on TTL in DNS has a planning approach.
2. Operating system caches can be flushed locally (ipconfig /flushdns, sudo resolvectl flush-caches, or sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS).
3. Browser caches hold their own copy; clear Chrome's at chrome://net-internals/#dns.
4. Routers and corporate DNS often cache too, and some ignore TTLs and hold records longer than they should. Testing from a phone on mobile data is a quick way to get a fresh resolver.

You can see how long a resolver will keep its current answer by reading the TTL it returns — it counts down as the cache ages:

dig @8.8.8.8 www.example.com A +noall +answer

The second column is the remaining TTL in seconds. When it reaches zero, that resolver will fetch the new value.

A Quick Checklist

When a domain stops resolving after a change, run through this in order:

1. Does dig @<authoritative-ns> name +norecurse return the new record?
2. Does the TLD server delegate to the nameservers you expect?
3. Do all nameservers return the same SOA serial in dig +nssearch?
4. Is there a DS record, and does the +cd test reveal a DNSSEC failure?
5. Are glue records current, if your nameservers live in your own domain?
6. Do public resolvers show the old value with a TTL still counting down?

The first five are configuration problems you fix. Only the sixth is a waiting game.

---

Domain Not Resolving After a DNS Change FAQ

Conclusion

"Wait for propagation" is good advice only when the problem really is caching, and you can prove that in a couple of minutes. Query the authoritative nameservers directly, confirm the parent zone delegates to the right ones, and check that every nameserver agrees. If all three are correct, resolvers are just serving cached data and time will fix it.

If any of them is wrong, you have a configuration problem: records edited at a provider that isn't serving the zone, a new provider without a complete zone, a stale DNSSEC DS record, outdated glue, or a zone file typo. Each of these will persist indefinitely until you fix it, and each one is straightforward to fix once you know it's there. Building the habit of verifying at the authoritative source before and after every change is the best way to make DNS changes boring.

These references go deeper into delegation, caching, and validation behavior:

1. RFC 1034: Domain Names - Concepts and Facilities — defines delegation, authoritative data, and resolver caching.
2. RFC 2308: Negative Caching of DNS Queries (DNS NCACHE) — specifies how long NXDOMAIN answers may be cached.
3. RFC 4035: Protocol Modifications for the DNS Security Extensions — describes DNSSEC validation, including the CD flag and why mismatched DS records cause failures.
4. BIND 9 Administrator Reference Manual: bind9.readthedocs.io — documentation for dig, named-checkzone, and zone management.
5. Cloudflare Learning Center: What is DNS? — an overview of how resolvers, TLD servers, and authoritative servers interact.