DNS propagation in 2026: resolver speed and answer divergence

Propagation usually means the time it takes for a record change to reach every resolver. That quantity is not measured directly: it is set by the TTL of the previous answer, not by the speed of any server. If the old record carried an hour, an hour is how long it lives in caches — whoever you ask.

So two other things can be measured, and both are more useful: how fast each resolver answers and whether different resolvers give the same answer. The second is what people usually see when they say "mine has updated but my colleague’s hasn’t".

On 27 August 2026 we queried five public resolvers for 600 domains — 3,000 queries. From a single vantage point: Moscow, on the Selectel network.

A caveat without which the table cannot be read: latency to a resolver is set by the network path from the measuring point, not by the resolver’s quality. These are numbers for one Moscow server on one network, and from elsewhere the order may differ. They are not a general ranking of resolvers.

Note the tail: OpenDNS has the worst median among the quick ones yet the shortest p99 — 547 ms against Cloudflare’s 1,187. For DNS that often matters more than the average: a one-second stall on a critical lookup is more noticeable than a steady extra forty milliseconds.

Empty answers came out alike across all five — 51 to 57 of 600, or 8–10%. That agreement is a good sign: every resolver concurs on which domains do not resolve at all, so the method is not skewed.

We compared the address sets five resolvers returned for the same domain:

At first glance this looks like an advantage for the Russian web: steadier answers. In fact the opposite holds, and the cause matters more than the figure.

Resolver divergence is almost always a trace of geographic DNS. A content delivery network deliberately returns different addresses to different resolvers so as to send a visitor to the nearest node. A domain behind such a CDN must give different answers — that is the whole point. A domain on one fixed address gives everyone the same one.

So the divergence rate measures CDN prevalence, not DNS quality. Four percent in .ru against thirty in .org is another measurement of the same fact we obtained from alt-svc headers and from short TTLs. Three independent signals, one conclusion.

1. Lower the TTL in advance. A day before a migration set five minutes and wait for the old value to expire. TTL cannot be shortened retroactively — it is the only lever, and it works only before the change.
2. Do not panic at differing answers on a CDN-backed site. If a delivery network serves your domain, different resolvers should return different addresses. That is not a propagation fault.
3. Check against the authoritative server, not a public resolver. Querying your NS directly shows what you have published; querying 8.8.8.8 shows what is cached. Those are different questions, and confusing them is the commonest source of a false alarm.
4. Remember the cache on your own machine. The operating system and the browser cache separately from your provider, and "it hasn’t updated for me" often means exactly that.

To see how an answer varies across resolvers, use the propagation checker; for a domain’s full record set, the DNS lookup.