A public DNS resolver can look like a tiny settings change: replace one IP address with another and get on with the day. But the resolver is also a policy decision. It can validate DNSSEC, block domains classified as malicious, filter other categories, or resolve names without content filtering. And it can become entangled in legal orders that reach beyond the network operator.
That question is newly concrete. Quad9 says it will stop offering its free cyberprotection service to users in France on November 24, 2026, after a French court ruling it says creates legal risks for the service. The important detail is not simply that one resolver is leaving one country. It is that public DNS providers can face pressure to make blocking decisions, while users often treat resolver addresses as interchangeable infrastructure.
This is a practical comparison of Quad9 and Cloudflare's 1.1.1.1 service, based on their published documentation. It is not a speed benchmark or a hands-on privacy audit. The short version: choose Quad9 when threat-domain blocking is part of the policy you want; choose standard Cloudflare 1.1.1.1 when you want an unfiltered public resolver; choose neither as your only security control.
First, separate resolution from filtering
A recursive resolver looks up DNS records on behalf of a device. When a browser needs an address for a hostname, it asks a resolver, which finds or returns the answer. A public resolver is operated by a third party rather than by your local network or internet provider.
Filtering is an additional policy. A resolver may refuse, alter, or sinkhole answers for selected domains. That can help block access to known malicious destinations, but it can also create false positives and adds a policy layer between the user and the domain. DNS filtering does not inspect every connection or stop threats that use a direct IP address, a compromised legitimate domain, or another path that bypasses the resolver.
Encryption is a separate property. DNS over HTTPS (DoH) and DNS over TLS (DoT) protect the connection between a client and a resolver from passive observers on the local network path. They do not make the resolver unable to see the query, and encrypted transport does not itself authenticate the DNS data in the same way DNSSEC validation does. The DNS over HTTPS specification explicitly distinguishes transport security from DNSSEC response integrity.
That gives you three questions, not one: who receives your DNS queries, what filtering policy do they apply, and what protections validate or encrypt the exchange?
What the two services actually offer
Quad9's common secure endpoint. Quad9's 9.9.9.9 service combines threat blocking with DNSSEC validation. Its documentation lists two IPv4 addresses, two IPv6 addresses, a DoH endpoint, and a DoT hostname. Quad9 also offers other resolver variants, including one without threat blocking and one with EDNS Client Subnet (ECS) enabled. The endpoints are not identical with a different label: they represent different feature choices.
A no-filter Quad9 endpoint is not the same as its secure endpoint. Quad9's 9.9.9.10 service disables threat blocking, while its current service-address page says DNSSEC validation is enabled on all resolver addresses. Its 9.9.9.9 endpoint combines threat blocking with DNSSEC validation. Cloudflare's standard 1.1.1.1 resolver does not filter content; its Families variants add malware filtering, with another option that also filters adult content. Compare the exact endpoint features rather than assuming a provider's variants share one security profile.
Privacy statements are provider commitments, not independent audits. Quad9 describes its service as privacy-focused and says it does not store client IP address data. Cloudflare publishes specific commitments for its public resolver, including restrictions on retaining source IP data in non-volatile storage, with a stated exception for a small randomly sampled portion of network packets used for troubleshooting and denial-of-service mitigation. These are useful disclosures to compare, but this article does not independently verify either provider's internal systems.
The legal-policy distinction matters. Quad9's announcement says its service will no longer be available to users located in France from November 24. Cloudflare's public-resolver policy says it does not filter content through standard 1.1.1.1 and describes how it would approach government requests. These statements describe current provider positions; they are not guarantees about future legal outcomes or identical service availability everywhere.
A practical choice matrix
Use these questions to decide:
- Do you want known malicious domains blocked at DNS? Quad9's 9.9.9.9 endpoint is explicitly threat-blocking. Cloudflare's standard 1.1.1.1 is not. Cloudflare's Families variants provide their own malware filtering.
- Do you want a general-purpose, unfiltered resolver? Standard 1.1.1.1 is the clearer fit based on Cloudflare's published description. Quad9's 9.9.9.10 variant disables threat blocking, but still provides DNSSEC validation according to its current service documentation.
- Do you need adult-content filtering for a home network? Cloudflare offers a Families endpoint for malware and adult-content filtering. Quad9's documented primary distinction is threat blocking, not an equivalent adult-content category filter.
- Do you depend on CDN location accuracy? Quad9 documents an ECS-enabled service variant for users who do not route to a nearby Quad9 location. ECS changes what location information is conveyed in DNS requests, so weigh the routing benefit against your privacy requirements. Do not enable it just because it exists.
- Is encrypted DNS required? Both providers publish encrypted DNS options. Configure the client with the provider's documented endpoint and authentication name, then verify the active resolver. Merely entering a familiar IP address does not prove that queries use DoH or DoT.
- Are you in a jurisdiction where availability or filtering obligations are changing? Check the provider's service notices and your network's actual resolution behavior. A resolver address can remain configured even when its service policy or reachability changes.
For many individual developers, the real choice is not “which is fastest?” but “which policy do I want, and can I observe when it fails?” A millisecond difference measured once is a weak reason to outsource every hostname lookup to a different organization.
Configure one resolver on Linux with systemd-resolved
Do not blindly edit /etc/resolv.conf. NetworkManager, DHCP clients, VPN software, and systemd-resolved may regenerate it. First see which service manages DNS:
resolvectl status
readlink -f /etc/resolv.conf
If your distribution uses systemd-resolved, save the existing configuration before changing it. The following example sets Cloudflare's standard resolver over DNS over TLS. To use Quad9's encrypted endpoint instead, replace the hostname with dns.quad9.net and use the Quad9 address shown in its service documentation.
Edit /etc/systemd/resolved.conf and set:
[Resolve]
DNS=1.1.1.1#one.one.one.one
DNSOverTLS=yes
Cloudflare documents the #one.one.one.one authentication name and DNSOverTLS=yes form for systemd-resolved. Quad9 publishes dns.quad9.net as its DoT service name. Confirm the exact configuration for your distribution and systemd version before applying it; a typo in the authentication name can break encrypted resolution.
Then restart the resolver and inspect its status:
sudo systemctl restart systemd-resolved
resolvectl status
resolvectl query example.com
A successful lookup only proves that a name resolved. It does not, by itself, prove which upstream handled it or that the connection was encrypted. Check resolvectl status for the configured DNS server and DNS-over-TLS state. For a stronger test, inspect traffic from a controlled environment or use the provider's own verification guidance. Avoid pasting real browsing queries into public diagnostic sites.
If you choose plain DNS by IP instead, configure both documented IPv4 addresses and the matching IPv6 addresses where applicable. Quad9 specifically recommends configuring all addresses for a selected service to avoid a single-path failure. Do not mix addresses from different Quad9 variants: a secure and an unsecured endpoint in the same list can make behavior inconsistent with the policy you intended.
Test the policy, not just the connection
Before changing a work laptop, a family router, or a production resolver, write down the current DNS settings and a rollback path. Then test a few separate things:
- Resolution: Can the system resolve ordinary domains after the change?
- Transport: Is the client using the encrypted protocol you configured, rather than silently falling back to plaintext?
- Filtering: Does the selected endpoint block only the categories its provider documents? Use the provider's official test guidance, not a random malware domain.
- Failure behavior: What happens when the primary endpoint is unreachable? Does the client switch to the intended backup, use a VPN's resolver, or fall back to the ISP?
- Network changes: Does the configuration survive reconnecting Wi-Fi, enabling a VPN, rebooting, or joining a captive portal?
- Application behavior: Do browsers, containers, and command-line tools use the system resolver, or have they configured their own DoH endpoint?
This last question is easy to miss. An operating system resolver setting may not control a browser configured for its own secure DNS, a container with custom DNS, or a VPN client that pushes resolver settings. The effective policy is the one each application actually uses, not the one you intended to configure globally.
What DNS filtering cannot promise
A threat-blocking resolver is a useful layer, not an endpoint-security product. It can block a domain when that domain is queried through the resolver and appears on its threat list. It cannot guarantee that every malicious host is known, that every application uses the configured resolver, or that a safe-looking domain is not compromised later.
Likewise, encrypted DNS is not anonymity. The resolver still receives the questions needed to answer you. Encryption mainly changes who can observe or modify the query while it travels between your device and the resolver. A VPN, browser, enterprise endpoint agent, or local network policy may also choose a different route.
The Quad9 France announcement makes the governance question visible, but it does not prove that every public resolver will respond the same way, that a particular user's traffic was exposed, or that switching providers defeats a legal block. Keep the practical scope modest: understand the provider's stated policy, configure the intended endpoint, test the actual path, and retain another layer of security.
A resolver-selection checklist
Before committing, answer these six questions:
- What filtering do I want: none, malware-only, or another category?
- Is DNSSEC validation enabled on the exact endpoint I selected?
- Is DNS transport encrypted from this device or network?
- What information does the provider say it retains, and what has not been independently verified?
- What happens if the resolver is unreachable or changes service in my region?
- Do my VPN, browser, containers, and router follow the same resolver policy?
If you cannot answer the last two, start by measuring and documenting your current behavior. Then make one change, test it, and keep a rollback. DNS configuration is infrastructure, not a magic security switch.
I write about developer tools, security, and practical infrastructure. Subscribe if you want more pieces like this.
Have you chosen a public DNS resolver for a specific filtering or privacy reason? What behavior did you verify after configuring it?
Save this checklist before changing DNS on a device or network you depend on.
Top comments (0)