Privacy DNS Resolvers Compared: What Each One Keeps

Every connection you make starts with a question somebody else answers. Before your browser can open an encrypted session to a site, something has to turn the hostname into an address, and that something receives the name in full. Not the page you read, not the account you signed into, but the fact that you asked for that host, at that time, from your address.

That list is unusually revealing for how little data it holds. It is short, it is timestamped, and it covers everything: the bank, the health service, the job board, the thing you searched at 2am. Your internet provider sees roughly that set if you use its resolver, which by default you do.

Changing it takes a couple of minutes. The useful part is knowing what you are changing it to, and most comparisons rank providers on speed, the axis that matters least.

The one machine that sees every name#

Your resolver learns the full hostname. The authoritative servers it queries on your behalf learn parts of the name and, depending on a setting covered below, something about your network. The site you eventually reach learns your address anyway, the moment the connection opens. The resolver is not the only observer, then, but it is the only one assembling a complete list without you ever connecting to it deliberately. It is also a bounded improvement: a good resolver fixes one thing and leaves the rest of your exposure untouched.

Encryption hides the query from the network#

Two standards wrap DNS in transport encryption. DNS over TLS comes from RFC 7858, which is direct about where it lives: a server supporting it "MUST listen for and accept TCP connections on port 853." DNS over HTTPS comes from RFC 8484, which "defines a protocol for sending DNS queries and getting DNS responses over HTTPS," mapping each query and response pair into an ordinary HTTP exchange.

Both close the same gap: everything between you and the resolver, from the coffee shop router to anyone passively recording in the middle. Neither changes what the resolver itself sees, because the resolver is the party doing the decrypting. Encrypting to an operator you have not thought about relocates the exposure rather than removing it.

That is why the provider question comes before the protocol question. Our comparison of DoH and DoT covers how the two transports differ in practice, including why one is far harder for a network to block.

What the big resolvers say they keep#

Cloudflare runs 1.1.1.1 and 1.0.0.1, with 2606:4700:4700::1111 and 2606:4700:4700::1001 on IPv6. Its published resolver policy states that "all Public Resolver Logs are deleted within 25 hours," and that "a Public Resolver user's IP address will not be stored in non-volatile storage." Addresses are anonymised by truncation, dropping the last octet of an IPv4 address and the last 80 bits of an IPv6 one. Sampled aggregates may be kept for analytics.

Google Public DNS runs 8.8.8.8 and 8.8.4.4, and splits its logging in two. Temporary logs contain the full client address and are "subject to our deletion processes within 24-48 hours," with an exception for investigating abuse. Permanent logs are described as "a sampling of the temporary logs where your IP address is removed and replaced by a city or region-level location," and Google specifies that location as no more precise than one square kilometre and a thousand users.

Quad9 runs 9.9.9.9 and 149.112.112.112, and operates out of Zürich, Switzerland, having been founded by the Global Cyber Alliance, IBM and PCH. Where an operator sits is a jurisdictional difference rather than a technical one, though for some readers it decides the question.

Read all of those as policies, not as properties of the system. A retention promise describes what an operator intends to do with data it is fully capable of keeping, and you cannot verify it from your side. What you can compare is how specific each promise is: a published figure someone could later be held to says more than a paragraph about respecting privacy.

The client subnet question#

This is the axis most roundups skip, and it is the one where the providers genuinely diverge.

When a resolver queries an authoritative nameserver, that server normally sees only the resolver's own address, which locates your resolver rather than you. RFC 7871 defines EDNS Client Subnet to close that gap, carrying "information about the network that originated a DNS query and the network for which the subsequent response can be cached."

The cost is that a piece of your network address now travels to every authoritative server your resolver consults, not just to the resolver you picked. The RFC does not soften this. It states plainly: "We recommend that the feature be turned off by default in all nameserver software, and that operators only enable it explicitly in those circumstances where it provides a clear benefit." It defines an opt-out, in which "a SOURCE PREFIX-LENGTH value of 0 means that the Recursive Resolver MUST NOT add the client's address information to its queries," and then concedes that support for those opt-out provisions is "currently limited."

The three resolvers land in three different places:

• Cloudflare does not send it. Its documentation answers the question directly: "1.1.1.1 is a privacy-focused resolver and does not include client IP information in its queries to authoritative servers. It does not send the EDNS Client Subnet (ECS) header." The one documented exception is an Akamai debugging domain used for cross-provider testing.
• Quad9 splits it across addresses. Its standard service does not send ECS, and a separate service that does is published on 9.9.9.11 and 149.112.112.11. You choose by which address you configure.
• Google uses it and logs the prefix. Its permanent logs record the ECS protocol and prefix length while excluding the client address itself.

There is a real trade here, and it cuts against the privacy answer. Without client subnet data, a content network has less to work with when picking an edge server for you, and you can land further away than necessary. That matters less than it used to: most large networks now steer traffic with anycast routing rather than with DNS answers, which we walk through in how one IP address lives in many places.

Filtering is a separate decision#

Several of these operators will refuse to resolve names they consider malicious, and it is easy to file that under privacy because it arrives through the same setting. It is a security feature, and the two goals pull against each other.

Quad9's standard addresses block known-malicious domains. Its unfiltered service lives on 9.9.9.10 and 149.112.112.10, documented as being for experts only, because it drops that blocking. Cloudflare uses the same shape at different addresses: 1.1.1.2 and 1.0.0.2 for malware blocking, 1.1.1.3 and 1.0.0.3 for malware and adult content.

Blocking is genuinely useful. It stops a category of attack before a connection is attempted, and it covers every device on the network at once, including the ones you cannot install software on. Just notice what it requires: a resolver that evaluates each name you request against a threat list, which is the same visibility you were trying to narrow. That is a reasonable trade, right up until someone assumes a blocking resolver is automatically the more private one.

DNSSEC validation is integrity, not privacy#

A validating resolver checks the signature chain on a signed answer and refuses one that has been tampered with along the way. Quad9 enables that validation on all of its resolver addresses, including the unfiltered ones.

The property it buys is authenticity, not secrecy. DNSSEC does not encrypt anything, and a signed answer is as readable to anyone on the path as an unsigned one. It answers "is this answer genuine," while DoH and DoT answer "who could read the question." A resolver worth using does both. You can check whether a domain is signed with our DNSSEC validator, and DNSSEC explained covers how the chain of trust is built.

The resolver you set is not always the one you get#

This is where most of the effort gets wasted. Several layers can each override the one below it, and none of them announces that it has done so.

• Your router hands out its own address over DHCP, so a change made on one device can be undone the next time it reconnects.
• A VPN client usually pushes its own resolver for the life of the tunnel, replacing what you configured.
• Browsers can run their own encrypted DNS independently of the operating system, so one application resolves through a different provider than the rest of the machine.
• Some networks intercept outbound port 53 and answer with their own resolver regardless of what you asked for, which is part of why the encrypted transports exist.

The way to settle it is to look. Our DNS leak test compares the resolver answering for you against the network your connection is on, and names it outright when it recognises a well-known operator: Cloudflare, Google Public DNS, Quad9, OpenDNS, AdGuard, Control D and dns0.eu. Its scope is worth stating honestly, since it observes the network path rather than the resolver setting stored on your device. Treat a surprising result as a prompt to check your configuration, not a verdict on it. Our guide to DNS leak testing goes through how to read the outcome, and the DNS records lookup shows what the authoritative side publishes for a domain you are troubleshooting.

Picking one#

If your concern is how many parties learn something about your network, pick a resolver that does not forward client subnet data. Cloudflare states that it does not, and Quad9's standard addresses do not either, with the ECS variant kept separate so you have to opt into it.

If your concern is malicious domains, take a blocking variant on purpose rather than by accident: Quad9's standard addresses, or Cloudflare's 1.1.1.2 and 1.1.1.3 families. Treat adult-content filtering as its own question, because it is its own address.

If your concern is retention, compare the published numbers rather than the marketing. Cloudflare's 25 hours and Google's 24 to 48 hours for full-address logs are the commitments the two have put in writing, and Google's second tier keeps a sampled, address-stripped record beyond that.

Whichever you choose, do the two things that make the choice real. Set it as high up as you can, at the router if the router will let you, so every device inherits it. Then encrypt to it, and verify that the resolver answering is the one you picked. A resolver you changed six months ago and never checked is worth exactly as much as the last piece of software that quietly overrode it.