ConfigureHow

DNS explained, and whether changing your resolver helps

Published . 7 min read

Changing your DNS resolver will almost never make web pages load noticeably faster, because your browser answers most repeat lookups from its own memory before the resolver hears the question. Three other reasons do justify a switch: content filtering, the operator's written retention policy, and somewhere to fall back to when a provider goes dark.

What actually happens when you type a hostname

Four roles do the work, named by RFC 9499 (BCP 219, March 2024), which obsoleted RFC 8499. An explainer still citing 8499 is out of date.

The stub resolver in your operating system "cannot perform all resolution itself". It hands the question to a recursive resolver, which chases the answer down the delegation chain and, because it caches what it learns, is more precisely a full-service resolver. An authoritative server answers for a zone from local knowledge. A forwarder passes queries to another resolver instead of walking the chain itself.

Your home router is a forwarder. Your ISP's resolver usually is not: it does the recursion itself. Either way it reads every query you send it.

The header bits come from RFC 1035 section 4.1.1, not RFC 1034: RD (Recursion Desired) "directs the name server to pursue the query recursively", RA (Recursion Available) says whether it can. Both set in the reply means recursion happened.

The chain starts at the root. There are 13 root server identifiers, A through M, run by 12 independent organizations, a naming artifact rather than a hardware count: those letters were served by 2,001 operational instances at 08:03 UTC on 27 July 2026. Root, then TLD, then authoritative server, then the record: your resolver makes that walk rarely, the point of the next section.

TTL, caching, and the 2023 rule most explainers missed

RFC 2181 pins the TTL as "an unsigned number, with a minimum value of 0, and a maximum value of 2147483647". It also deprecates differing TTLs inside one RRset, and the recovery rule is not the "use the lowest" folklore: from a non-authoritative source you discard the RRset and ask an authoritative one, and only from an authoritative source do you treat every record as carrying the set's lowest TTL.

RFC 9520, published December 2023, is the change most older writeups predate. Resolvers "MUST implement a cache for resolution failures", not merely for NXDOMAIN answers, for at least 1 second and no longer than 5 minutes. It also tightens RFC 4035's permissive MAY: security-aware resolvers now MUST cache DNSSEC validation failures. Repair a broken delegation or a bad signature and a validating resolver can legitimately keep serving the failure for five more minutes. Flushing your client cache does nothing, because the failure is not held there.

RFC 8767 (March 2020) covers the opposite case: a resolver may serve expired records past their TTL, but only when it cannot reach any authoritative server, and it suggests a 30 second TTL on those answers. That is an outage valve, not something to design around.

Why a faster resolver rarely speeds up a page

The decisive mechanism sits in the browser. Chromium keeps its own DNS cache in front of the operating system, and the numbers are blunt. Resolving through the system's getaddrinfo(), it never learns the real TTL, so every entry stays fresh for a flat 60 seconds (kCacheEntryTTLSeconds = 60). Resolving names itself, via its built-in resolver or DoH, it honors the real TTL but enforces a 60 second minimum anyway.

So any domain you touch twice inside a minute, nearly every asset host on a page you are already reading, is answered in process in well under a millisecond and never reaches your resolver. Resolver latency applies only to genuinely cold lookups, where benchmarks put the gap between major public resolvers in the single-digit to low-double-digit millisecond range. A few milliseconds on a minority of lookups is not something a human perceives.

Where a browser DNS lookup stops A left to right chain of four stages: the browser with its own Chromium DNS cache, the operating system stub resolver, a recursive resolver run by an ISP or a public operator, and the delegation walk from root to TLD to authoritative server. A bracket under the first stage marks where most repeat lookups end, because Chromium keeps a name for a flat 60 seconds when it resolves through the system and enforces a 60 second minimum when it resolves names itself, so a name touched twice inside a minute is answered from process memory in well under a millisecond. A second bracket spans the other three stages, the cold lookup path, which is the only side that choosing a different resolver changes, and where benchmarks put the gap between major public resolvers in the single-digit to low-double-digit millisecond range. Browser Chromium DNS cache OS stub resolver hands it onward Recursive resolver ISP or public The delegation walk root, TLD, authoritative Most repeat lookups end here Chromium keeps a name for a flat 60 seconds when it resolves through the system, and enforces a 60 second minimum when it resolves names itself. Touch a name twice inside a minute and the answer comes from process memory, in well under a millisecond. Only a cold lookup gets here Choosing a different resolver only changes this side. Benchmarks put the gap between major public resolvers in the single-digit to low-double-digit millisecond range.
The 60 second floor belongs to the browser, not the resolver, which is why clearing the operating system cache so often changes nothing.

Encryption works against you here, mildly. A DoH query rides inside an HTTPS request, TLS handshake and HTTP framing wrapped around the DNS payload, and RFC 8484 binds its caching to ordinary HTTP rules: freshness "MUST be less than or equal to the smallest TTL in the Answer section". None of that targets speed. If a site feels slow, DNS is not where your time is going.

DoH, DoT and DoQ

TransportSpecRuns onWhat the spec pins down
DoTRFC 7858 (May 2016)TCP port 853Servers MUST listen on 853; no cleartext DNS allowed there
DoHRFC 8484 (October 2018)HTTPS, GET or POSTLooks like any other HTTPS; freshness capped at the smallest answer TTL
DoQRFC 9250 (May 2022)QUIC, UDP port 853One stream per transaction, so a slow answer blocks nothing else; in Unbound since 1.22.0

All three encrypt exactly one hop: you to the resolver you chose.

What encrypted DNS does not hide

Three gaps.

The operator still sees every query. The IETF's own post on DoH says the server "is able to infer important information about the user such as their interests, their likely location, and so on", and names the real problem: "the overriding issues around DoH can be characterized as related to 'centralization.'" Encryption moves your trust; it does not remove the need for it.

The destination IP address is still in plaintext. Your machine then connects to that address, and the IP header is readable by everyone on the path.

The hostname is usually still in plaintext too, in the TLS ClientHello's SNI field, unless Encrypted Client Hello runs at both ends. That gap dates older articles. ECH stopped being a draft in March 2026, published as RFC 9849 after draft-ietf-tls-esni reached version 25, and it leans on encrypted DNS: that is what lets a client fetch ECH config keys from a DNS HTTPS record without leaking the name it is hiding. Firefox has shipped ECH since version 119 in October 2023. Cloudflare enables it by default on Free zones only. NGINX added native ECH in 1.29.4 in February 2026, though that build still needs OpenSSL's ECH feature branch, since ECH is not in a stable OpenSSL release yet.

What encrypted DNS covers, and what stays in plaintext A fork diagram with two paths leaving your device. The upper path goes to the resolver you chose and is the only leg that DoH, DoT or DoQ encrypts; that resolver still reads every query, and the IETF notes the operator can infer a user's interests and likely location. The lower path goes to the site you asked for and carries no DNS encryption at all: the destination IP address sits in the IP header for everyone on the route to read, and the hostname is usually readable too, in the TLS ClientHello SNI field, unless Encrypted Client Hello runs at both ends. The resolver you chose reads every query you send it DoH, DoT or DoQ encrypts this hop The IETF notes the operator can infer a user's interests and likely location. Encryption moves your trust, it does not remove the need for it. Your device browser and OS The site you asked for plus everyone on the path no DNS encryption covers this leg The destination IP is in the IP header, readable by everyone on the path. The hostname usually is too, in the TLS ClientHello SNI field, unless Encrypted Client Hello runs at both ends.
All three gaps sit outside the encrypted leg, so no choice between DoH, DoT and DoQ closes any of them.

None of this is DNSSEC, which authenticates the answer and says nothing about who watched the question. APNIC reported validation at 36% and secure delegation at 7% for 2025, so most answers you get are unsigned whatever carried them.

The three reasons that do justify switching

ResolverPriceDefault filteringStated handling of your IP
Quad9 (9.9.9.9)Free, Swiss foundationMalware, phishing, spyware, botnets"Does not collect or record user IP addresses"
Cloudflare (1.1.1.1)FreeNoneTruncated, then deleted within 25 hours
NextDNSFree to 300,000 queries/month; Pro EUR 1.99/month, currency may localizeConfigurable, all features freePer-account logging setting
DNS4EUFree86.54.11.1 protective, .12 adds child protection, .13 adds ad blocking, 86.54.11.100 unfilteredResolved inside the EU by Whalebone

For filtering, try NextDNS free first: blocking is not paywalled, only volume is, and 300,000 queries a month is roughly 10,000 a day.

For policy, read the text, not the marketing page. Quad9 says it "does not collect or record user IP addresses", nor any "proxy for or representation of user IP addresses", while conceding aggregate counters "may be kept in full or partial form in permanent archives". Mozilla's Trusted Recursive Resolver policy is another yardstick: partners "must not retain that data for longer than 24 hours". Cloudflare is that program's regional default for US, RU and UA users; CIRA is Canada's.

Reliability is underrated. On 14 July 2025 Cloudflare's 1.1.1.1 went dark globally for 62 minutes, 21:52 to 22:54 UTC, when a dormant misconfiguration from 6 June withdrew the resolver's prefixes. "The majority of 1.1.1.1 users globally were affected," Cloudflare wrote, and the cause was "an internal configuration error and not the result of an attack or a BGP hijack". The outage hit the IP addresses, so DoH users pointing at cloudflare-dns.com were largely unaffected.

Routing around a block is a weaker plan than it was

The old advice, point at a public resolver to escape an ISP-level block, has a 2026 problem. On 18 March 2026 the Paris Judicial Court issued seven simultaneous orders covering 19 French ISPs, the resolvers run by Google, Cloudflare and Quad9, and VPNs including Proton VPN, CyberGhost and ExpressVPN, to block 35 sports piracy domains for beIN Sports France. On 17 April the same court ordered Whalebone, operator of the EU-funded DNS4EU, to block 16 MotoGP and 21 Formula 1 stream domains, by default judgment after Whalebone did not appear. Whalebone went further than required: "For the DNS4EU Public Service, we do not restrict these filtering measures to French traffic only. These blocks apply globally across our resolver tiers." Public resolvers are blocking targets now. That is documented for France; check your own jurisdiction.

What to check when DNS really is the problem

A record change that looks like it has not applied is usually the 60 second browser floor, not a stale upstream cache. Inspect and clear that cache at chrome://net-internals/#dns. Connecting a VPN or switching Wi-Fi flushes it anyway.

Internal hostnames that stop resolving after you turn on encrypted DNS are the classic self-inflicted failure. The DoH endpoint bypasses your router's resolver, so nas.local or a split-horizon company name has nowhere to come from. Chrome's Secure DNS is usually both cause and fix. Its default: "secure DNS in Chrome is turned on in automatic mode. If Chrome has issues looking up a site in this mode, it'll look up the site in the unencrypted mode." That changes the transport, not the organization reading your queries.

On restrictive networks DoT fails where DoH succeeds: TCP 853 is trivial to block, DoH looks like any other HTTPS session. DoQ has the same exposure on UDP 853.

If you configure a primary and a secondary, make the secondary a different organization. 1.1.1.1 and 1.0.0.1 are both Cloudflare, and July 2025 withdrew both at once.

Sources