DNS Propagation Checker

Our checker sends the same question to nine public resolver addresses in parallel: Google Public DNS (8.8.8.8 and 8.8.4.4), Cloudflare (1.1.1.1 and 1.0.0.1), Quad9 (9.9.9.9) and OpenDNS (208.67.222.222 and 208.67.220.220), with 8.8.8.8 and 9.9.9.9 asked twice. It then compares the answers and reports which resolvers agree with the majority.

All of those queries leave one DNSX server in Europe. Each resolver address is anycast, announced from dozens of data centres, and the query lands at whichever is closest to our server. So the results show what the Google, Cloudflare, Quad9 and OpenDNS caches near Europe currently hold. They are not measurements from different countries, and a resolver node in Singapore can hold a different cached copy. For most changes this is still the useful view, because these four networks answer a large share of all DNS queries, and once they have picked up a change it is effectively live.

The tool checks A records by default and can query AAAA, MX, TXT, CNAME and NS records instead. Each row shows the answer and the response time.

Every DNS record carries a time to live, in seconds. When a recursive resolver fetches a record from the authoritative server, it stores the record with that TTL and answers from its cache until the TTL counts down to zero. Only then does it ask the authoritative server again. Nothing is pushed out to resolvers when a record changes, so the old value lives on in every cache that holds it for as long as the TTL that was in force when it was fetched.

This is why the TTL to lower is the one on the old record, and why it has to be lowered in advance. If a record has an 86,400-second TTL and you change its value and its TTL at the same time, resolvers that fetched it an hour ago will hold the old value for another 23 hours, because the TTL they hold is the old one. Lower the TTL to 300 seconds, wait at least 24 hours so every cached copy with the old TTL has expired, make the change, confirm it with our checker, then raise the TTL back to something sensible so resolvers are not fetching it every five minutes forever.

Resolvers also cache the fact that a name does not exist. RFC 2308 defines negative caching: when the authoritative server answers NXDOMAIN or returns no records of the requested type, the resolver remembers that for a period taken from the minimum field of the zone's SOA record (or the SOA TTL, whichever is lower). If you look up a name before you create it, the resolver you used may keep answering that it does not exist for that long after you add it.

The negative TTL is set by the zone as a whole, not per record, and many providers use 3,600 seconds or more. Create the record before testing it, and if you have already tested, use a resolver that has not seen the name yet or wait out the SOA minimum.

Open Command Prompt or PowerShell. nslookup takes a resolver address as its last argument, so you can ask a public resolver and an authoritative nameserver in turn and compare the two answers. The PowerShell cmdlet Resolve-DnsName does the same with -Server and prints the TTL column, which nslookup only shows with -debug.

nslookup -type=NS example.com
nslookup example.com a.iana-servers.net
nslookup example.com 8.8.8.8
Resolve-DnsName example.com -Type A -Server 1.1.1.1

macOS ships dig, so no install is needed. The authoritative nameservers hold the zone itself and never cache, so their answer is the one every resolver will eventually pick up. Find them with an NS query and then ask one of them directly with the @ syntax. On an authoritative answer the TTL after the name is the full configured value.

$ dig NS example.com +short
a.iana-servers.net.
b.iana-servers.net.

$ dig @a.iana-servers.net example.com A +noall +answer
example.com.    3600    IN    A    93.184.215.14

dig comes from the dnsutils package on Debian and Ubuntu and from bind-utils on Fedora and RHEL. Ask a public resolver with the @ syntax and compare its answer with the authoritative one. On a cached answer the TTL is the time left, so it tells you how long the resolver will keep serving the old record.

$ dig @8.8.8.8 example.com A +noall +answer
example.com.    2417    IN    A    93.184.215.14   # 2417 seconds left in Google's cache

$ dig @a.iana-servers.net example.com A +noall +answer
example.com.    3600    IN    A    93.184.215.14

If the authoritative answer is wrong, the change was never made or was made in the wrong zone, and no amount of waiting will fix it. If the authoritative answer is right and a resolver differs, the resolver is caching and the remaining TTL tells you how long. Our DNS lookup can query the authoritative nameservers for you with the Authoritative resolver option.

• Large caches. Google and Cloudflare run many independent cache nodes per location. Two queries to 8.8.8.8 a second apart can hit two nodes with different expiry times, which is why our checker asks 8.8.8.8 twice and both rows can differ.
• Filtering. Quad9 blocks names on its threat feeds and answers NXDOMAIN for them. OpenDNS does the same for categories its users have chosen. An empty answer from one of these while the others agree is filtering, not propagation.
• GeoDNS. CDN-hosted domains answer with the address closest to the resolver that asked. Different resolvers legitimately get different A records, and none of them is stale. MX, TXT and NS records rarely vary this way, so checking one of those is a cleaner propagation test for such domains.
• ISP resolvers that ignore TTL. Some ISP resolvers enforce a minimum cache time of hours regardless of the record's TTL. Our checker does not query ISP resolvers, so a change that looks complete here can still be stale for customers of such an ISP until their floor expires.
• Serve-stale. RFC 8767 lets a resolver keep answering with an expired record while it is unable to reach the authoritative server. If your nameservers were unreachable during the change, resolvers may hold the old answer longer than the TTL.

Your computer, your browser and your router keep caches too. Flushing them only affects what you see, but it helps when the public resolvers already agree and your browser still opens the old site.

# Windows (Command Prompt or PowerShell)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux with systemd-resolved (Ubuntu, Fedora, Debian 12 and later)
sudo resolvectl flush-caches

# Linux with nscd
sudo systemctl restart nscd

# Chrome and Edge, in the address bar
chrome://net-internals/#dns  then "Clear host cache"