Pi-hole and Unbound: what changes when you run your own DNS resolver
Pi-hole is the internet address book with a blocklist for your home network. It decides which names your devices may look up, then normally sends every allowed request to one public or internet-provider resolver for the actual address. Add Unbound and your own hardware does that looking-up instead of asking one big public directory.
That is a real change in who holds the record of your lookups. It is not anonymous DNS, it does not make your lookups invisible, and it does not block a single extra tracker.
Why this matters
A public resolver can receive a broad stream of the names your household asks for. Its privacy policy, logging practices and uptime become part of your home network.
Unbound is a validating, recursive and caching DNS resolver (NLnet Labs). In plain terms: it can look names up from the top of the DNS hierarchy itself, check that signed answers have not been tampered with, and keep a local copy of recent answers. Pi-hole still makes the allow-or-block decision. Unbound only finds and checks the answers for names Pi-hole has allowed.
The flow becomes:
Device → Pi-hole policy → Unbound cache and recursion → DNS hierarchy
NLnet Labs is explicit about the limit. Parts of an ordinary lookup still leave your network, and they may be visible to network observers or to the servers that hold the records (Resolver for Home Networks). You have stopped concentrating everything at one upstream provider. You have not made DNS disappear.
At a glance
| Question | Practical answer |
|---|---|
| Helps with | Dependence on one public resolver, local caching and DNSSEC validation |
| Does not solve | Anonymity, all DNS visibility, traffic that bypasses Pi-hole, or advertising served from the same domain as wanted content |
| Difficulty | Medium; higher if the network uses IPv6, more than one router or enforced DNS rules |
| Relative cost | Low on suitable hardware you already run; higher if you need reliable dedicated hardware or a second unit |
| Maintenance | Software updates, health checks, configuration backup, bypass testing and a written outage plan |
| Ordinary-user fit | Best when installed and supported by someone comfortable diagnosing DNS failures |
Cost bands are relative and exclude labour. Fit depends on the router, operating system and network design.
What Pi-hole and Unbound help with
Less concentration at one resolver. One public resolver no longer receives the complete set of allowed lookups simply because it is the only place Pi-hole forwards them.
Local caching. Repeat lookups can be answered from the local copy while the saved record is still valid.
DNSSEC validation. For domains that publish signed DNS records correctly, Unbound can check the chain of signatures. That helps catch forged or corrupted answers. It does not encrypt the connection, and it does not prove the website itself is honest.
Clearer custody. The resolver’s configuration, cache and logs stay under your control, or that of whoever maintains it for you.
Pi-hole remains the filtering layer. The project describes Pi-hole as a network-wide DNS sinkhole that blocks listed domains without installing software on every device (Pi-hole documentation). Unbound does not replace its lists, its groups, its client view or its dashboard. If you are new to Pi-hole, start with what Pi-hole blocks and what it misses.
What this does not solve
Parts of your lookups stay visible to your internet provider, the networks in between, the root and top-level domain servers, and the server that holds a domain’s own records.
It also does not close the paths Pi-hole already misses:
- an app that uses its own encrypted DNS service (DNS over HTTPS or DNS over QUIC)
- a device on a VPN, connecting to a direct IP address, or using its own mobile connection
- advertising and wanted content delivered from the same hostname
- what a service records about you inside an account you chose to use
- data collected before the control was installed
Mozilla notes that application-level DNS over HTTPS can bypass a local resolver and its special network policies (Mozilla). Firewall rules (the rules on the doors between your network and the internet) can close some common bypasses, but that is separate design work with its own ongoing tests. Unbound alone cannot force a device to use it. And neither component removes malware from a device that already has it.
Decide the failure policy before installing anything
DNS is small but critical. When it fails, people say “the internet is down” even though the connection itself is fine.
Choose deliberately between three approaches:
- Fail closed: filtering and local resolution stop rather than quietly sending lookups somewhere else. Your privacy policy stays consistent, but an outage interrupts normal use.
- Documented emergency bypass: an authorised person can temporarily switch to a known public resolver while repairs happen. Service returns, but filtering and local custody are reduced until you switch back.
- Local redundancy: a second maintained Pi-hole and Unbound pair keeps answering. No single point of failure, but double the configuration, update and testing work.
Do not add a public resolver beside Unbound and assume it will sit idle until something breaks. Resolver selection can favour whichever upstream answers fastest, so a “backup” may be handling routine lookups. Check what your software version actually does before you call it a backup.
A safe implementation path
1. Prove the existing Pi-hole setup first
Confirm that representative devices actually use Pi-hole, over both IPv4 and IPv6. Test browsing, streaming, work logins, smart-home control and software updates. Export the Pi-hole configuration and write down the current upstream resolver so rollback is a simple change.
2. Use a supported host and the official instructions
Run Unbound on maintained hardware with reliable storage and an accurate clock. Follow the current NLnet Labs and Pi-hole documentation for your operating system; package names, defaults and configuration locations change. Do not copy an old configuration from an unverified forum post.
3. Keep the resolver private
Set Unbound to listen only on the local address and port that Pi-hole uses. Never expose it to the internet as an open resolver. Restrict administration to trusted devices and keep the host’s own firewall rules narrow.
4. Configure recursion and validation deliberately
Use the current list of root servers and the trust anchor (the starting key Unbound uses to check signatures) the way the official documentation recommends. Match the IPv6 settings to what your connection really provides; telling Unbound it has IPv6 on a host without reliable IPv6 can cause delays. I change one setting at a time and keep a copy of the last working configuration.
5. Test Unbound directly
Before involving Pi-hole, use a DNS test tool to ask the local Unbound address for several ordinary domains. Confirm successful answers, sensible response times and that repeat lookups come back from the cache. Run the DNSSEC checks in the current official Pi-hole and NLnet Labs documentation: one correctly signed domain that should pass, one deliberately broken one that should fail. A validating resolver should accept a correctly signed answer and reject a broken one.
6. Point Pi-hole at the local resolver
Add the tested Unbound address as Pi-hole’s upstream. Remove the previous upstreams only once the new path is stable. Repeat the device tests, then confirm in Pi-hole’s query log that allowed requests are being forwarded to the intended local address.
7. Check for bypasses
Test a normal browser, a browser with secure DNS switched on, a phone, a television and at least one managed work device. Compare the device settings, the Pi-hole log and, where you have them, the firewall’s observations. Devices on their own network need the same check; see the IoT network guide.
8. Keep resolver logging to a minimum
DNS history can reveal banks, health services, workplaces and daily routines. Keep only the detail you need to run the system, restrict who can read it, protect the backups and write down whether remote support can view queries.
9. Write down the recovery path
Record the host address, the local port, where the configuration lives, the Pi-hole upstream setting, the backup location and the emergency DNS procedure. Keep the instructions somewhere you can reach when DNS is already broken.
Failure and recovery tests
A setup is not finished until these tests have passed:
- Clean restart: restart Unbound, then Pi-hole, then the whole host. Normal resolution should return without anyone improvising.
- Unbound stopped: stop only Unbound and confirm the failure policy you chose is what happens. Restore it and measure how quickly devices recover.
- Pi-hole stopped: confirm that devices either fail or use the documented emergency path, not an unknown resolver handed out by IPv6 or a second router.
- Validation test: repeat the valid and deliberately invalid DNSSEC checks after major updates.
- Bypass test: enable secure DNS in a test browser and confirm whether the network permits, redirects or blocks it as your policy says.
- Configuration restore: restore the Pi-hole and Unbound settings from backup in a safe test environment or during a planned maintenance window.
- Power recovery: after a controlled outage, confirm the host comes back with the expected address and the services start in the right order.
Keep the previous known-good Pi-hole upstream details handy. Rollback should be a deliberate configuration change, not a panicked router reset that wipes unrelated settings.
If a UniFi gateway is filtering too
If a UniFi gateway is also filtering content or redirecting DNS, map the whole path before enabling Unbound. The gateway should not quietly capture queries meant for Pi-hole or send internal names to the wrong resolver. Decide which component filters, which one resolves allowed names and how devices are held on that path, then test forwarding, local names, IPv4, IPv6 and recovery. The UniFi router security guide covers what the gateway can do on its own.
When Alien IT can help
An Alien Privacy Box may suit a household or small organisation that wants Pi-hole, optional Unbound, conservative filtering, documented recovery and proper testing without owning every setup detail.
It will not make the network anonymous, and it cannot guarantee that every device uses local DNS. Fit depends on the router, how the devices behave, the IPv6 design and the maintenance arrangement. We confirm those boundaries before we propose a configuration.
Want your own resolver set up properly, with the recovery path proven before you rely on it? Alien IT can help. Call 02 9707 0999 or use the contact page.
Frequently asked questions
Is Unbound more private than a public DNS resolver?
It can stop one recursive provider receiving your complete stream of allowed lookups. Parts of each lookup still leave your network during recursion, so “more distributed custody” is more accurate than “private DNS”.
Does Unbound encrypt DNS?
Ordinary recursion is not the same as an encrypted tunnel to one provider. DNSSEC validates signed answers; it does not hide the question. Encryption and validation solve different problems.
Will it make Pi-hole block more trackers?
No. Pi-hole’s lists and rules decide what is blocked. Unbound changes how the permitted names are looked up.
Can I use Unbound without Pi-hole?
Yes. Unbound is a resolver in its own right. Pi-hole adds network-wide rules, blocking and a useful view of what your devices ask for.
Why did the internet stop when the server rebooted?
Devices may be unable to look up names while Pi-hole or Unbound is unavailable, or the host may have come back with a different address. Check the services are running, the host has the expected address and the upstream setting matches your notes before changing unrelated router options.
Should I keep a public resolver as a backup?
Only with a tested design and an explicit policy. A parallel upstream may receive routine lookups, sidestep your validation choices or hide failures from you. A second maintained local resolver is cleaner but costs more effort.