Why your DNS resolver choice changes page load times

A DNS lookup costs one round trip before the browser can even open a TCP connection. On a 40 ms link that is 40 ms of dead time per uncached domain, and a typical page touches a dozen of them. Resolver choice is not a rounding error.

Three separate problems people conflate

When a site feels slow to start, it is usually one of these, and they have different fixes:

1. Resolver latency — how far the recursive resolver is from you.
2. Cache hit rate — whether the resolver already knows the answer.
3. Answer correctness — whether the IP you get back is the one the operator intended.

Switching to a fast public resolver fixes the first and often worsens the third.

The correctness problem is the one that bites

In networks where DNS answers are rewritten in transit, a resolver that returns "fast" responses can return wrong addresses. The failure mode is confusing: the connection succeeds, TLS may even complete, but you land on the wrong server or get a reset. It looks like a server problem, not a DNS problem.

The diagnostic is to compare answers from two vantage points:

dig +short example.com @223.5.5.5
dig +short example.com @1.1.1.1

If they disagree for a domain that should have a single origin, you have found a rewritten answer. For domains behind a CDN the two will legitimately differ, so pick your test domains carefully — use something with one authoritative answer, not a CDN-fronted site.

Encrypted transport helps, but only end to end

DNS over TLS or HTTPS prevents rewriting between you and the resolver. It does nothing about the resolver itself lying, and nothing about the last mile if your queries are being intercepted before they leave.

The practical arrangement that avoids both:

client -> local resolver -> encrypted upstream -> recursive resolver

with the encrypted upstream reached over a path you control. That last clause is the whole point. An encrypted query to a resolver you cannot reach directly is just a slower plaintext query.

Splitting by domain beats picking one resolver

Domestic domains resolve faster and more accurately through domestic resolvers, because the authoritative servers are closer and the CDN mapping is correct. Everything else benefits from a resolver that is not subject to rewriting.

The usual pattern is a rule set:

if domain matches domestic-list  -> domestic resolver
else                             -> encrypted remote resolver

Two things to get right. First, the rule set needs periodic updates or it silently rots. Second, and more subtly, the resolver used for outbound connection setup is a separate setting from the resolver used to answer client queries. Configure only the second and your own proxy connections will still be resolving through the wrong path — which shows up as "some sites work, some hang".

Measuring it honestly

Clear the cache before each measurement or you are timing your own resolver:

dig +short example.com @resolver   # note the query time
dig +short example.com @resolver   # second call, cached

Report the cold number. The warm number tells you nothing about the resolver and everything about your cache.