DNS propagation: fourteen resolvers, judged against the source

What it is, and who it is for

DNS propagation is one of ten instruments on the labs.llc domains desk. You give it a name and a record type; it puts the question to fourteen public resolvers and, beside them, to the domain’s own authoritative nameservers, so every answer is judged against the source. Each cached copy’s remaining lifetime is counted down live.

It is for site owners and administrators who have just changed a record and need to know who still holds the old answer, and for how much longer.

How it works

This instrument does its asking on the server, through a same-origin relay (domains/whois/tools.php, op=dns). It does not trust a single answer when it looks for the authority: it asks the parent zone’s servers, takes a referral from a parent server with recursion off, resolves every nameserver, checks that each address is public, and asks each one with recursion off (tools_dns.php lines 16–24). Only then are the fourteen resolvers asked the same question over UDP port 53, with EDNS NSID requested so the page can name the anycast node that answered.

The list reaches past the usual Western set: Google, Cloudflare, Quad9, OpenDNS, Level3, AdGuard, Hurricane Electric, CleanBrowsing, UltraDNS, Comodo and DNS.SB, plus Yandex in Moscow and 114DNS and Baidu inside mainland China. The browser script, dc-dns.js, then applies three rules: the authoritative answer is the truth the others are measured against; a resolver that did not answer counts as no answer, never as agreement; and a different answer is not automatically an old one — location-aware DNS, filtering resolvers and the national firewall are named as likelier reasons, marked as probable (lines 18–24).

• What it reads
• Fourteen public resolvers, asked directly over UDP 53
• The domain’s own authoritative nameservers, found through the parent zone and asked with recursion off
• All through domains/whois/tools.php on the labs.llc server

What we measured, and when

At 20:15:42 UTC we asked the local copy for wikipedia.org, type A. The relay answered in 0.33 seconds (322 ms inside the engine), uncached, after 25 DNS questions and no errors. Three Wikimedia nameservers answered with authority — the aa flag set, TTL 180, serial 2026060420 — giving 208.80.154.224. All fourteen resolvers answered; ten matched the authority. Yandex and 114DNS returned 185.15.59.224, DNS.SB 103.102.166.224 and Baidu 31.13.68.169. Remaining lifetimes ran from 2 seconds at Cloudflare to the full 180.

The verdict it drew was not “not propagated”. It read four different answers from fourteen resolvers as geo-DNS suspected, and said a different address here is expected and is not a stale record; its notes named the filtering resolvers and the two mainland-China resolvers separately, each reason marked probable. That caution is earned: three of the odd answers end in .224, as the authority’s does, but Baidu’s 31.13.68.169 does not, so geo-DNS alone may not explain it. The desktop capture is from 20:14:19 UTC.

390 × 84420:14:24Z

12

Beside DNSChecker.org and whatsmydns.net

Each comparator was checked on the date shown. We say what each does better before we say where DNS propagation goes further.

Where it falls short

• All fourteen resolvers are asked from one place — the labs.llc server — so each anycast answer comes from the node nearest that server, not from your city. The page says so; the two map-based checkers present answers from servers in many regions.
• Ten record types; no SRV, PTR or DNSKEY.
• Twenty fresh readings a minute and 600 a day per visitor, and no way to add your own resolver.

The verdict