{"id":426,"date":"2026-08-30T10:10:00","date_gmt":"2026-08-30T08:10:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?p=426"},"modified":"2026-10-24T01:12:11","modified_gmt":"2026-10-23T23:12:11","slug":"dns-level-ad-blocking-security-pi-hole-and-adguard-home-in-a-unifi-network","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/raspberry-pi\/dns-level-ad-blocking-security-pi-hole-and-adguard-home-in-a-unifi-network\/","title":{"rendered":"DNS-Level Ad Blocking & Security: Pi-hole and AdGuard Home in a UniFi Network"},"content":{"rendered":"

Pi-hole and AdGuard Home filter DNS queries: requests for domain names can be blocked before a connection starts. This can reduce advertising and tracking from separate domains across many devices. It does not inspect page contents or remove individual advertisements served from the same domain as wanted content. Direct IP connections, alternative resolvers and tunnels can bypass DNS filtering.<\/p>\n

\"A
DNS filtering controls domain lookups on the configured path. Encrypted upstream traffic does not guarantee that every client uses that path.<\/figcaption><\/figure>\n

A clear DNS path across VLANs<\/h2>\n

A dedicated server VLAN is one possible location for the resolver, not a requirement for segmentation. A fixed address or DHCP reservation makes the service predictable. Each participating network can advertise the resolver through DHCP. IPv6 also needs a consistent DNS configuration through the mechanisms supported by the clients and gateway; an IPv4 setting alone does not cover IPv6.<\/p>\n

Firewall rules should allow client networks to reach only the approved resolver addresses on UDP and TCP port 53. The destination is the server\u2019s zone, not automatically the Gateway zone. Older UniFi rules use names such as LAN IN; current zone-based policies use source and destination zones. Administration of the resolver should remain restricted to authorized management clients.<\/p>\n

The resolver must also accept requests from the routed networks. Pi-hole\u2019s default local-only mode can reject other VLANs even when the firewall permits traffic. A suitable listening mode and firewall restrictions must be configured together. Opening DNS to the internet is unnecessary for this design.<\/p>\n

Encrypted upstream traffic<\/h2>\n

Upstream means the server to which the local filter forwards unanswered queries. AdGuard Home supports encrypted upstreams directly. Pi-hole can use a suitable local forwarding service; older instructions using cloudflared proxy-dns<\/code> are no longer a current installation method.<\/p>\n

DoT uses TLS, normally on TCP port 853. DoH carries queries through HTTPS, usually on port 443. Both protect the configured connection, not every link in the resolution chain. The selected provider still receives the queries. Encryption is not DNSSEC validation, which checks signed DNS data. DoH can be harder to distinguish from other HTTPS traffic, but is neither invisible nor impossible to block. Low latency is not guaranteed.<\/p>\n

Enforcement has limits<\/h2>\n

DHCP advertises DNS settings; it does not force applications to use those settings. A policy can allow the approved resolvers and block other plain DNS traffic from clients. Blocking may make an application fail instead of switching to the approved server. Resolver upstream traffic needs separate permission.<\/p>\n

Destination NAT can redirect matching plain DNS traffic where the gateway version and topology support the required rule. Exceptions for all approved resolvers, return routing and IPv4\/IPv6 behavior need explicit checks. A port-53 redirect does not capture DoH, DoT, a VPN or a connection that stays within a subnet without crossing the gateway.<\/p>\n

Lists of known encrypted DNS endpoints provide partial coverage and need maintenance. Blocking shared CDN addresses can break unrelated services. Managed browser policies or restricted internet access for a dedicated device network can be more predictable, but must match the required applications. UniFi\u2019s own Content Filtering also redirects DNS; combining both filters requires a deliberate design and verification of local names.<\/p>\n

Validation and operation<\/h2>\n

From each VLAN, checks should cover a permitted domain, a deliberately blocked test domain, internal names, TCP and UDP DNS, and the configured IPv6 path. Query logs show which resolver actually handled a request. Cached answers and existing connections can continue temporarily after a rule change. A high block percentage alone proves neither effective privacy protection nor a faulty application.<\/p>\n

\n

Questions and answers<\/h2>\n

What happens if the resolver fails?<\/h3>\n

New lookups can fail while cached names and established connections continue to work. A second filtered resolver improves availability only if the clients and firewall can actually reach that instance. A public secondary resolver can bypass the policy; client selection is not necessarily strict primary-then-secondary failover.<\/p>\n

Does Firefox\u2019s canary domain enforce filtering?<\/h3>\n

A negative answer for use-application-dns.net<\/code> signals Firefox to disable automatically enabled DoH under the documented conditions. It does not override an explicit user choice to enable DoH and is not a network-wide enforcement mechanism.<\/p>\n

How should false positives be handled?<\/h3>\n

A reproducible failure, the client\u2019s query log and a narrowly scoped temporary exception can identify the relevant domain. Exceptions should be reviewed after testing. DNS logs reveal browsing-related metadata, so access and retention should be limited to the operational need.<\/p>\n<\/div>\n

\n

Sources<\/h2>\n