How to Change Pi-hole's Upstream DNS Server

Why change DNS on Pi-hole

Pi-hole sits in the middle of your network: your router or your devices point their DNS at the Pi-hole, and for every hostname lookup Pi-hole either answers it from cache, blocks it because it’s on a blocklist, or forwards it to an upstream resolver. That upstream is the DNS server Pi-hole itself trusts to translate everything it doesn’t block. By default many installs point at Google or your ISP; switching that to a resolver that responds faster from your location shortens the lookup delay before a page starts loading for every device on the network.

Be precise about what this does. Changing the upstream affects the speed and privacy of resolution — how quickly non-blocked lookups come back, and which company sees your queries — and nothing else. It does not change Pi-hole’s ad blocking: your blocklists (gravity) are applied by Pi-hole before it ever forwards a query, so the upstream never gets a say in what’s blocked. It also does not increase your bandwidth or speed up downloads; a faster resolver only trims the lookup step at the very start of a connection.

Before you pick one, run the DNS speed test from a device on this network to see which resolver actually responds fastest from your connection, then use its addresses as your upstream instead of the examples below. You can also compare resolvers on privacy and filtering — not just speed — on the public DNS servers page, and see our tuned picks on best DNS for Pi-hole.

Version and setup differences

The path Settings → DNS → Upstream DNS Servers is the same across current Pi-hole versions, but the surrounding interface has changed:

• Pi-hole v5 (classic interface). Upstreams appear as a two-column list of checkboxes (IPv4 / IPv6) for common providers, plus four editable “Custom 1–4” fields where you tick the box and type an IP. Save sits at the bottom of the page.
• Pi-hole v6 (current). The web interface was rewritten and served by Pi-hole’s own embedded web server, but DNS still lives under Settings → DNS. Upstreams are shown as a list you enable, and you add a custom resolver by entering its IP directly. A Basic/Expert toggle exposes extra options; you don’t need Expert mode just to set an upstream.
• Docker installs. The admin page and menu paths are identical; only the port mapping differs. If you mapped the container’s web port to something other than 80, include it in the URL (for example http://192.168.1.5:8080/admin).

Custom port syntax is the same everywhere: write it as IP#port (a hash, not a colon) — for example 127.0.0.1#5053. That matters for the encrypted setup below.

Encrypted DNS (DoH/DoT)

Here’s the honest limitation: Pi-hole has no native DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT). There is no toggle in Settings → DNS that encrypts the traffic between Pi-hole and its upstream — the Upstream DNS Servers box speaks plain DNS. Any guide claiming Pi-hole encrypts upstream queries out of the box is describing a setting that isn’t there.

The established way to get an encrypted upstream is to run a small proxy on the same host and forward Pi-hole to it over localhost:

• cloudflared (encrypted, DoH). Run cloudflared as a local DoH proxy listening on 127.0.0.1:5053, then set Pi-hole’s upstream to 127.0.0.1#5053. Now Pi-hole’s outbound queries leave the box encrypted. Our encrypted DNS setup helper generates the exact cloudflared config for your chosen resolver’s DoH endpoint so you can paste it in.
• unbound (recursive, not encrypted by itself). Run unbound as a local recursive resolver, usually on 127.0.0.1:5335, and set the upstream to 127.0.0.1#5335. This resolves from the root and authoritative servers directly instead of trusting one public provider — better privacy distribution — but the queries to those servers still travel as plain DNS unless you also configure unbound for DoT. Use unbound for recursion; use cloudflared (or unbound-with-DoT) when the goal is on-the-wire encryption.

Either way, the upstream field is where you wire it in: point it at your local proxy’s 127.0.0.1#PORT instead of a public IP. See best DNS for Pi-hole for how these options compare.

Verify it worked

Pi-hole makes this easy to check from the dashboard:

• Upstream servers chart. On the v6 dashboard the Upstream servers chart (labelled Forward destinations in v5) shows which upstream your non-blocked queries are actually going to. After a change it should list your new resolver — or 127.0.0.1#5053 if you switched to cloudflared.
• Query Log. Open the Query Log — a top-level item in the sidebar (the Queries view at /queries in v6) — run a lookup on a client, and confirm the query shows as forwarded to the expected upstream rather than the old one.
• Command line. From any client, run nslookup example.com <pi-ip> (or dig @<pi-ip> example.com). A fast, valid answer confirms Pi-hole is resolving through the new upstream. Then reload this site and run the DNS speed test again to confirm the resolver you picked is the one in use.

Troubleshooting

• Queries still show the old upstream. Pi-hole caches answers and reuses live connections. Reload its resolver with pihole reloaddns (that’s pihole restartdns on v5) so the change takes hold, or wait for cached records’ TTLs to expire.
• Lookups fail or return SERVFAIL after switching. The custom upstream IP is probably wrong or unreachable. Re-check each octet. If you pointed at cloudflared or unbound, confirm the service is actually running and listening on that port — for example sudo systemctl status cloudflared — because Pi-hole can’t reach a proxy that isn’t up.
• A custom port is being ignored. Use the IP#port format (hash, not colon). 127.0.0.1:5053 is invalid here; 127.0.0.1#5053 is correct.
• “Ad blocking stopped working after I changed the upstream.” It didn’t — the upstream has nothing to do with what Pi-hole blocks. If ads are getting through, that’s a blocklist/gravity issue, not the resolver; update gravity and check your lists, then revert the upstream only if you also changed it at the same time.
• The admin page won’t load. Confirm you’re using the Pi’s correct IP and the /admin path, and that you’re on the same network as the Pi-hole. For Docker, include the mapped port in the URL.

Revert to your old settings

Go back to Settings → DNS, untick the resolver (or clear the custom field) you added, re-enable whichever upstream you used before — a listed provider, or your previous custom IP — and click Save. Pi-hole restarts its resolver and immediately goes back to forwarding through the old upstream. If you set up cloudflared or unbound solely for this and no longer want it, point the upstream back to a public IP first, then stop the local service. None of this touches your blocklists or the rest of your Pi-hole configuration.