/commands/dns/check-dns-propagation
Check DNS propagation from the command line
- tool
- DNS
- versions
- BIND 9 dig
- os
- linux, macos, windows
"DNS propagation" is caches expiring, not data spreading. To check it, ask the zone's authoritative name servers first (they show the new value as soon as the zone is published), then ask a few recursive resolvers (they keep the old value until its TTL runs out). With dig: dig +short NS example.com, then dig @NS-SERVER example.com A +norecurse, then dig @RESOLVER example.com A and read the TTL column.
1. Ask the authoritative servers
dig +short NS example.com
dig @ns1.example-dns.net example.com A +norecurse
dig @ns2.example-dns.net example.com A +norecurseReplace the server names with the ones the first command prints. Every authoritative server should return the new value and the same SOA serial (dig @SERVER example.com SOA +short, the third field). If one returns the old value, the zone has not reached that secondary yet, and no amount of waiting at the resolvers helps.
2. Ask recursive resolvers
dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer
dig @9.9.9.9 example.com A +noall +answer
dig example.com A +noall +answer # your own configured resolver+noall +answer prints only the answer lines. The second column is the remaining TTL in seconds: a resolver that still returns the old address will switch once that number reaches zero. +trace follows the delegation from the root servers down, which shows the authoritative view without any cache in between.
Reading the results
| What you see | What it means |
|---|---|
| Authoritative servers return the new value, resolvers the old one | Normal; wait for the TTL shown by each resolver. |
| Authoritative servers disagree, serials differ | Zone transfer to a secondary failed or is pending; check the DNS provider. |
| status: NXDOMAIN from a resolver, the name exists at the authoritative server | Negative caching (RFC 2308); it lasts up to the SOA minimum/negative TTL. |
| NS records at the parent differ from NS in the zone | A registrar delegation change; the parent zone TTL (often a day or more) applies. |
| Your machine still uses the old value, public resolvers the new one | Local cache: flush the operating system or browser cache. |
Pitfalls
+shorthides the TTL, so it cannot tell you how long a stale answer will last. Use+noall +answer.- A
CNAMEin the answer means the address comes from the target name, which has its own TTL; see A record vs CNAME. - Errors such as
connection timed out; no servers could be reachedmeandigcould not reach that resolver at all (firewall, wrong IP), not that the record is missing. - On Windows without
dig,nslookup example.com 8.8.8.8asks a specific server, andResolve-DnsName example.com -Server 8.8.8.8 -DnsOnlyin PowerShell does the same and shows the TTL.
To confirm the change is complete, every authoritative server returns the new value and the resolvers you care about return it with a TTL that counts down from the full value you set.
FAQ
How long does DNS propagation take?
As long as the TTL that resolvers cached before the change. A record with TTL 3600 can be served stale for up to an hour after you edit it; a new name that was looked up while missing can stay missing for the negative TTL from the SOA record.
Why do online propagation checkers show different answers?
Each one asks a different recursive resolver, and each resolver cached the record at a different time. They converge when the old TTL has expired everywhere. If the authoritative servers disagree with each other, fix that first.
Can I make propagation faster?
Lower the TTL (for example to 300 seconds) a full old-TTL period before the change, make the change, then raise the TTL again. Changing the TTL at the same time as the record does not help caches that already hold the old one.