Pi-hole handles the blocking. The resolver you forward it to — the upstream — decides the speed, privacy, and security of every domain your network actually resolves. Here's how to choose one, and how to keep that hop encrypted.
The short answer
The best upstream DNS for Pi-hole is a fast, no-logging, DNSSEC-validating public resolver — Cloudflare, Quad9, dns0.eu, and Mullvad all qualify. Pi-hole already blocks ads, so skip ad-blocking upstreams; a malware-filtering resolver like Quad9 complements it instead of duplicating it.
Pi-hole sits on your local network as the DNS server every device talks to. When a device asks it for a domain, Pi-hole does three things in order: it checks the request against its blocklists and refuses anything on them, it checks its own cache for a recent answer, and only if the name is both allowed and uncached does it hand the question off to an upstream resolver — a public DNS service you configure in its settings. That upstream does the real recursive lookup and returns the address, which Pi-hole then caches and passes back.
The split is the whole point. Blocking and caching are Pi-hole's job; resolution is the upstream's job, and they're independent. So "the best DNS for Pi-hole" is not a question about how well something blocks ads — Pi-hole owns that — it's a question about which resolver you forward the surviving, allowed queries to. Pick badly and every real lookup your network makes is slow, logged, or leaked; pick well and the part Pi-hole delegates stays fast and private.
Three properties decide a good upstream, and none of them is ad blocking. In rough order of what people underestimate:
That last distinction is why an ad-blocking upstream is the wrong choice behind Pi-hole. Stacking a second DNS-level ad filter is redundant work, it makes a blocked page harder to diagnose because you can't tell which layer dropped it, and it doubles the blocklists you have to keep sane. Leave the ad and tracker blocking in Pi-hole, where you can inspect and whitelist it, and let the upstream do nothing but resolve — quickly, privately, and validated.
Here's the part that trips people up. By default, Pi-hole forwards to its upstream over plain port 53 — its resolver does not speak DNS-over-HTTPS or DNS-over-TLS on its own. So even if you type a no-log resolver's address into the upstream box, the queries leave your network in the clear, and your ISP (or anyone on the path) can still read every one. Choosing a private resolver protects who stores your lookups; encrypting the hop protects who can see them in transit. They are two separate steps.
There are two accurate ways to encrypt that hop. The first is to run a small encrypting proxy
on the same machine as Pi-hole — cloudflared (the tool in Pi-hole's own DoH
guide), dnscrypt-proxy, or stubby for DoT — and set Pi-hole's custom
upstream to that local listener (a loopback address and port). The proxy then re-sends every
forwarded query to your chosen public resolver over DoH or DoT. The second is to use a router
or gateway that supports DNS-over-TLS natively and point it at the resolver's DoT hostname,
listed in the table below. Either way, the resolver you picked still matters: encryption
secures the trip, the upstream's policy governs the destination.
Four resolvers that make sensible Pi-hole upstreams: each publishes a no-logging policy, validates DNSSEC, disables EDNS Client Subnet, and — importantly — does not block ads at the DNS layer, so it won't fight with Pi-hole. Addresses and features are pulled directly from our registry; confirm them against each provider before switching.
Cloudflare
The fastest major resolver on most connections, with a strong no-logging privacy stance and no default filtering.
1.1.1.1 1.0.0.1 
Quad9 Foundation
A security-first non-profit resolver that blocks known malicious domains and keeps no source-IP logs.
9.9.9.9 149.112.112.112 dns0.eu (non-profit)
A European, GDPR-compliant non-profit resolver. The default tier blocks malware and threats; the ZERO tier maximises privacy and KIDS adds family filtering.
193.110.81.0 185.253.5.0 
Mullvad VPN
Mullvad's free, encrypted-only public resolver (DoH/DoT). The default endpoint applies no filtering.
194.242.2.2 The properties that matter once ad blocking is off the table: retention policy, DNSSEC, whether the resolver adds a complementary malware layer, and the DNS-over-TLS hostname you'd hand to a proxy or router to encrypt the hop. Note that "ad blocking: no" is the desirable answer here — that job belongs to Pi-hole.
| Resolver | No-log policy | DNSSEC | Malware filtering | Ad blocking | DNS-over-TLS host |
|---|---|---|---|---|---|
| Cloudflare DNS | Yes | Yes | No | No — Pi-hole's job | 1dot1dot1dot1.cloudflare-dns.com |
| Quad9 | Yes | Yes | Yes | No — Pi-hole's job | dns.quad9.net |
| dns0.eu | Yes | Yes | Yes | No — Pi-hole's job | dns0.eu |
| Mullvad DNS | Yes | Yes | No | No — Pi-hole's job | dns.mullvad.net |
Because the fastest upstream varies by network, the honest way to choose is to measure. Run the free DNS speed test from a device on your network: it times each resolver directly, which approximates the hop Pi-hole would make on a cache miss. It can't measure Pi-hole's cache hits — those are local and effectively instant no matter what — so read the results as a comparison of candidate upstreams, not of your everyday browsing. Shortlist two or three resolvers from the table, see which answers quickest and most consistently on your line, then set that one as Pi-hole's upstream and encrypt the hop to it.
Point Pi-hole at a fast, no-logging, DNSSEC-validating public resolver. Cloudflare (1.1.1.1), Quad9 (9.9.9.9), dns0.eu, and Mullvad all fit that description and disable EDNS Client Subnet. There is no single fastest choice for everyone — latency to each depends on your ISP and location — so shortlist a couple and measure them from your own connection before you commit.
No. Pi-hole is already your ad and tracker blocker, so a second ad-blocking layer upstream is redundant. Worse, it makes false positives harder to trace — you can't tell which layer swallowed a request — and leaves you maintaining two blocklists. Keep the blocking in Pi-hole, where you can see and whitelist entries, and keep the upstream focused on plain, fast, validated resolution.
No. Pi-hole's resolver forwards queries to the upstream over ordinary port 53, in the clear. Even if you choose a no-log resolver, those lookups leave your network unencrypted and your ISP can still read them. To close that gap you run a local DoH or DoT proxy (such as cloudflared, dnscrypt-proxy, or stubby) and point Pi-hole's custom upstream at it, or you use a router that speaks DNS-over-TLS natively.
It can be a useful complement rather than a duplicate. Pi-hole's default lists mostly target advertising and tracking domains, not necessarily malware and phishing infrastructure. A security-first upstream such as Quad9 or dns0.eu blocks known malicious domains at the resolution step, filling a different gap without double-blocking the ads Pi-hole already handles.
Only on cache misses. Pi-hole caches answers, so repeat lookups for domains you've already visited are served locally and are near-instant no matter which upstream you use. A faster upstream shortens the first lookup of a new domain, or a lookup after its TTL expires. That's a real but narrow win — it does not increase bandwidth or make already-open connections faster.
If you enable DNSSEC in Pi-hole, pair it with a DNSSEC-validating upstream — all four resolvers here validate. One caveat: if you already resolve through a validating proxy or local recursive resolver, turning on validation again in Pi-hole duplicates the work and can cause confusing failures, so validate in one place rather than two.