Pi-hole or AdGuard Home on a Unifi Network: No-Drama Setup
Two clean ways to point a Unifi network at a Pi-hole or AdGuard Home box - plus the IPv6 and guest-network gotchas that catch most people on the first try.
You have Unifi gear running the network and either Pi-hole or AdGuard Home, the open-source network-level ad blocker and DNS server, sitting on a Raspberry Pi, NUC, or LXC container - and ads are getting blocked on the devices you've manually pointed at it. The bit that catches people out is routing the whole house through it without breaking the guest network, Chromecast streaming, or your laptop's IPv6 connectivity. This guide walks through the two clean paths and the four gotchas that consume an evening if you miss them.
What do you need before installing Pi-hole or AdGuard on UniFi?
This guide assumes you already have Pi-hole or AdGuard Home installed and working on at least one device. If you don't, start with our Pi-hole vs AdGuard Home comparison - they're functionally equivalent for ad-blocking at the network level, so pick whichever you find friendlier to manage. The Unifi configuration below works identically for either.
You'll also need to know the static IP address of your Pi-hole or AdGuard box. Make it static - DHCP-leasing the box that serves your DNS is asking for a 3am phone call. Most people give it 192.168.1.2 or similar; the exact number doesn't matter, but it has to not move.
Path 1: How does a network-level DNS override work?
This is the path most home setups should take. One change, one place, applies to every device on your main LAN.
In the Unifi UI: Settings → Networks → [your main LAN] → DHCP Service Management, the network setting controlling automatic IP address assignment, → DHCP DNS Server. Switch this from "Auto" to "Manual" and enter your Pi-hole's IP as the primary DNS. As a secondary, add a public resolver - Cloudflare's 1.1.1.1 or Quad9's 9.9.9.9 are sensible picks (see the fallback DNS section below for why you want a backup at all).
Save the change. Existing leases will keep using whatever DNS they were already issued until they renew - typically within 24 hours, often much sooner. To force the change immediately, you can either reboot the affected devices or release-and-renew the lease from the device side. On a Mac: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder after the lease renews picks up the new DNS.
Within five minutes you should see traffic showing up in your Pi-hole admin dashboard's query log from new devices on the LAN. If nothing is appearing, jump to the verifying-it-works section before assuming the change didn't take effect.
Path 2: How do you set per-network DNS for granular control?
If you have separate Unifi networks for IoT, guests, or kids and you want different DNS behaviour on each, configure DHCP-served DNS per network instead of globally. The settings live in the same place - Settings → Networks → [network name] → DHCP Service Management - you just configure each network independently.
The pattern most people end up with:
Main LAN: Pi-hole as primary, public resolver as backup. Maximum ad-blocking surface.
IoT network: Pi-hole as primary (catches the worst telemetry from smart-home devices), no backup - if Pi-hole goes down, you'd rather IoT stops working than starts phoning home unrestricted.
Guest network: Public DNS only (Cloudflare or Quad9). Guests don't sign up for Pi-hole; some guest devices break in confusing ways when DNS-level blocking is in play. Cleaner to bypass.
Kids / homework network: Pi-hole with stricter blocklists, or a separate Pi-hole instance with different rules.
What's the IPv6 gotcha that catches everyone?
Setting DHCP DNS only covers IPv4. If your ISP delivers IPv6 (most UK ISPs now do - Sky, BT, Vodafone, Virgin Media, and Hyperoptic all enable IPv6 by default), your devices will get a separate IPv6 DNS server via Router Advertisement (RA) - and they'll use that instead of your Pi-hole for any IPv6-resolved domain.
The fix lives at Settings → Networks → [network] → IPv6. Two changes:
Set DHCPv6 / RA Mode to a configuration that lets you specify a DNS server (rather than leaving it on the upstream-provided default).
Set IPv6 DNS Control to manual, and add your Pi-hole's IPv6 address as the DNS server. If your Pi-hole is IPv4-only, set the IPv6 DNS to :: (which signals "no IPv6 DNS, use the IPv4 one") - devices will fall back to the IPv4 Pi-hole correctly.
The symptom of skipping this step is the most confusing one in the whole setup: most ads block correctly, but a stubborn handful (usually the analytics scripts on bigger sites) still slip through. The query log in Pi-hole shows the device, but the malicious domain doesn't appear because that lookup went to the ISP's IPv6 DNS instead. If you see that pattern, you forgot the IPv6 step.
What happens when your Pi crashes - and how do you fall back?
Pi-hole running on a Raspberry Pi is generally reliable, but the SD card it's installed on usually isn't. SD-card wear-out kills Pis at unpredictable intervals; AdGuard Home in an LXC container on a Synology has its own failure modes. When the DNS goes down, everyone in the household notices within about ninety seconds and they all blame you.
The configuration above lists a secondary DNS (Cloudflare or Quad9). When the primary fails, devices fall back to the secondary, the household keeps working, and you have time to fix the underlying problem without an audience.
The objection to a public fallback DNS is that it bypasses your ad-blocking when in use. That's true - but the alternative (no fallback) means a Pi failure brings down internet access for everyone, which is worse than "ads come back for a few hours." A more robust setup is two Pi-hole instances on two physical devices, both listed as primary and secondary in your Unifi DHCP settings - this is what most serious self-hosters end up with.
Should your guest network block or bypass Pi-hole?
Most home Unifi setups have a guest network. The question is whether guests should route through your Pi-hole.
Bypass is usually the right answer. Guests bring devices you don't control. Their phone might be using DNS-over-HTTPS that bypasses your Pi-hole anyway, but the bigger concern is when DNS-level blocking confuses a captive-portal sign-in, a streaming app, or a corporate VPN. The diagnosis path is "why doesn't my friend's [thing] work?" while you're trying to enjoy a Saturday evening.
Set the guest network's DNS to a public resolver and move on. The marginal ad-blocking you'd get isn't worth the support burden.
How do you verify it actually works?
Three checks, in order:
Lookup test from a client device. On macOS or Linux: dig +short example.com @your-pi-hole-ip. On Windows: nslookup example.com your-pi-hole-ip. You should get a real IP back. If the command hangs or returns SERVFAIL, your Pi-hole isn't reachable from the network - check that you allowed port 53/udp through any firewall.
Default DNS test (no explicit server). Drop the @your-pi-hole-ip and just run dig +short example.com. The result should still resolve. If it does, the DHCP-served DNS is being picked up by the client.
Query log check. Open the Pi-hole admin dashboard and look at recent queries. You should see lookups from your client device. If you don't, the client is using a different DNS - most likely a hard-coded one (Chromecast does this, some IoT devices do too) or DNS-over-HTTPS in the browser.
Which four common gotchas matter most?
Chromecast and Google Home devices hard-code 8.8.8.8. They ignore your DHCP-served DNS and ask Google directly. The fix is to use Unifi's firewall to block outbound port 53 to anything except your Pi-hole - then the Google devices fall back to whatever DNS the DHCP gave them. This is also why Pi-hole won't catch some YouTube analytics until you do this.
DNS-over-HTTPS (DoH) bypasses your local DNS entirely. Chrome, Firefox, Edge, Safari, and most modern apps support DoH and may have it enabled by default. The browser sends DNS queries straight to Cloudflare or Google over HTTPS, never touching your Pi-hole. The workaround is to disable DoH in browser settings on the devices you care about (browser-level DNS settings, then "Use secure DNS" toggle off).
iOS Private Relay does the same thing for iCloud users on the Plus plan. Private Relay encrypts DNS and routes through Apple's servers. You can disable it per-device in Settings → [your name] → iCloud → Private Relay, or per-network in Wi-Fi → [network name] → Limit IP Address Tracking off.
Some IoT devices and routers have hardcoded DNS in firmware. Smart TVs, some streaming sticks, and (ironically) some cheap routers will ignore DHCP and use a hardcoded resolver. The fix is the same as the Chromecast one - firewall-block outbound port 53 except to your Pi-hole.
Frequently asked questions
Q01Does this work the same way with AdGuard Home as it does with Pi-hole?
Q02Will this slow down my internet?
Q03What if I want to use this with the Unifi Dream Router specifically?
Q04Can I run Pi-hole on the Unifi gateway itself?
Q05What if my Pi-hole dies - do I have to redo all this?
Pi-hole vs AdGuard Home: Which Should You Run?
What Is Pi-hole and Why Every Smart Home Needs One
Unifi Dream Router Review
