Pi-hole is a DNS server that filters queries against domain rules and blocklists. When a device asks for a blocked hostname, Pi-hole returns a configured blocking response instead of its ordinary address. The decision applies to that lookup; it does not inspect page content or terminate an existing connection. That boundary explains both its usefulness and the ads that remain visible.
The default blocking mode returns 0.0.0.0 for blocked A queries and :: for blocked AAAA queries. Other modes can return NXDOMAIN or a response without address records. A blocked lookup therefore does not always look like a DNS error. Use the query log’s status and your configured blocking mode to interpret it.
Blocking happens at the name, not the content
Because the decision is made on a hostname, blocking is all or nothing for that name. If advertising or telemetry is served from a domain used for nothing else, it disappears cleanly across every device on the network, including phones, smart TVs and appliances that cannot run a browser extension.
If content and advertising share the same hostname, DNS cannot separate them. Blocking that name breaks the service; allowing it lets everything through. This is why some platforms remain unaffected no matter which lists you add, and why a list promising to fix them usually just breaks playback instead.
Blocking also has no effect on anything requested by a literal address rather than a name, since no lookup happens.
Every client must actually use it
The sinkhole only sees queries sent to it. The usual way to arrange that is to hand out its address as the DNS server, either through the existing router’s DHCP settings or by letting Pi-hole serve DHCP itself. The second option is more reliable on routers that refuse to advertise a custom resolver.
A common and quiet failure is configuring the sinkhole as one of two DNS servers alongside a public resolver. Clients are free to use either, so results become inconsistent and blocking appears to work only sometimes. List one resolver, or list two instances that both do the filtering.
Some devices ignore the network settings entirely and use hardcoded resolvers, or encrypt their queries so they never appear as normal DNS traffic. Handling those requires firewall rules that redirect or reject outbound DNS from anything other than the sinkhole. Encrypted DNS inside applications is harder still and is often only addressable by disabling the feature on the client.
When blocking works on some devices and not others, first check whether the device’s queries arrive at all. The ordered diagnostic for that is in Pi-hole not blocking ads.
Why DoH and DoT can bypass Pi-hole
DNS-over-HTTPS and DNS-over-TLS protect DNS transport. They do not inherently decide whether a domain is allowed. The important question for filtering is which resolver receives the query and whether Pi-hole is in that path.
DoH, defined in RFC 8484, carries DNS messages in HTTPS requests. If an application uses a public DoH service directly, that service answers the application’s lookups. Pi-hole cannot apply its domain rules to messages it never receives. A working operating-system DNS setting does not establish that every application follows it.
DoT, defined in RFC 7858, establishes a TLS connection to a DNS server, normally on TCP port 853. A client using an external DoT resolver likewise places resolution outside Pi-hole. Redirecting ordinary port 53 traffic does not intercept that separate connection, and a plaintext DNS listener cannot accept the client’s TLS session as ordinary DNS.
| Query path | Does Pi-hole apply its lists? | What to check |
|---|---|---|
| Client sends DNS directly to Pi-hole | Yes, according to its client and group rules | Query log and assigned lists |
| Client queries Pi-hole, whose upstream transport is encrypted by another service | Yes, before allowed queries reach the upstream | Keep the local and upstream roles distinct |
| Browser queries an external DoH service directly | No | Browser policy and the chosen resolver |
| Operating system queries an external DoT service directly | No | Device resolver settings and permitted destinations |
| Application uses a literal IP address | No DNS lookup to filter | Whether domain filtering can meet the requirement |
The practical implication is that adding an encrypted upstream to Pi-hole does not make clients use Pi-hole. Conversely, disabling an application’s separate resolver does not encrypt its local DNS traffic. Decide on the filtering path and transport requirements separately, then check both.
Enforce Pi-hole use on clients you manage
Start with the router or DHCP settings described in Pi-hole’s post-install guide. Advertise only the filtering resolvers intended for that network. Configure one device first, confirm its received DNS settings, and check an actual application lookup before rolling the change out. Record the previous settings so a resolver outage does not leave you guessing how to restore service.
Browser policy can make the intended DNS path explicit. Mozilla’s DNSOverHTTPS policy controls whether Firefox enables DoH, which provider it uses, whether users can change the setting, and whether it falls back to the system resolver. On managed Firefox installations meant to use the system’s Pi-hole resolver, disable the separate DoH path and lock that policy. An alternative approved encrypted provider must itself preserve the intended filtering path; selecting an arbitrary public provider would not do that.
The Firefox canary domain is a narrower mechanism. Mozilla documents that a negative response for use-application-dns.net can disable automatically enabled DoH. It does not override a user’s explicit decision to enable DoH. It is a browser-specific signal, not enforcement for every browser or device. Do not use a successful canary check as evidence that all household DNS is filtered.
For each managed device, inspect the operating-system resolver settings and any application-level secure DNS setting. If the application offers its own resolver, document whether it follows system DNS or an approved service. Recheck after policy changes. For an unmanaged guest device, describe filtering as the network default rather than promising that every application must use it.
Firewall enforcement has a defined scope
Netgate’s DNS enforcement recipe permits the approved resolver before blocking other DNS destinations. Applied to a separate Pi-hole host, allow clients to reach that host on both TCP and UDP port 53, then reject other client DNS destinations. Preserve the resolver host’s own upstream access. Rules must match the relevant client interfaces and address families; a restriction on one VLAN does not establish policy for another.
Unapproved DoT on TCP 853 needs a separate restriction. DoH commonly uses HTTPS port 443, so blocking ordinary DNS ports does not cover it. Blocking known resolver destinations may help, but is not complete control of application DNS. Blocking HTTPS indiscriminately would also prevent ordinary web access. Use endpoint policy where you control the client and keep the firewall’s limits explicit.
Include routed clients and IPv6
Pi-hole’s default interface behavior accepts queries from locally attached subnets. A client on another VLAN may need a different listening mode and firewall permissions. Follow the interface documentation and restrict access to the intended clients; a broader listening mode is not an access-control rule. Keep DNS and the dashboard inaccessible from the public internet.
Review IPv6 resolver advertisements independently of IPv4 DHCP. Check the resolver addresses actually received by a client, then verify that lookups through each advertised path arrive at the intended filter. Looking up an AAAA record is insufficient evidence: the AAAA record describes an IPv6 destination, while the DNS query itself could have travelled over IPv4.
Verify the policy one client at a time
Use a short controlled check on your own network instead of judging by the number of visible ads:
- Confirm that the client received the intended resolver addresses. Check the application’s DNS settings as well as the operating system’s.
- Open Pi-hole’s query log, or use
pihole tail, and make a fresh lookup from that client. Account for any configured privacy or logging restrictions before interpreting missing entries. - Temporarily add a harmless domain you can spare, such as
example.org, to a deny rule assigned to the client. Confirm the blocked status and expected answer, then remove the rule. - Check the client’s group membership if queries arrive but that rule does not apply. Pi-hole’s per-client examples show that group assignments determine which lists and exceptions reach each device.
- Repeat through the browser and on each relevant network segment. An explicit query to Pi-hole proves the server can answer; it does not prove the browser chose it.
Cached answers and existing connections can outlive a policy change. A missing new query is therefore not enough to identify an encrypted-DNS path. Retry after clearing the relevant client cache or waiting for the cached answer to expire, and compare the application’s behavior with the resolver log. Keep the temporary rule’s removal in the checklist so diagnosis does not become a permanent source of breakage.
Upstream resolution is a separate decision
Allowed queries that Pi-hole cannot answer locally or from cache go to an upstream resolver. That operator sees those forwarded queries. Running the documented local Unbound recursive resolver avoids sending all of them to one public recursive service; authoritative DNS servers still receive the queries needed for resolution. It also adds a service to maintain.
Neither option encrypts anything by itself. Choose based on who you would rather not hand a query log to. Encrypted transport is a separate feature again, and the split between projects that build it in and projects that expect you to add it is one of the real differences covered in Pi-hole vs AdGuard Home.
Lists, breakage and diagnosis
Blocklist quality matters far more than blocklist quantity. Large aggregated lists overlap heavily and increase the odds of blocking something you need, and the resulting breakage is confusing because the application usually reports a generic connection error rather than a DNS failure.
The query log is the diagnostic tool. When a site or app misbehaves, look at what was blocked at that moment and allow the specific name rather than removing an entire list. Watch for lookups that redirect through an unrelated domain, a technique used specifically to make tracking hostnames look first-party.
Availability
Once devices depend on it for name resolution, an outage on the sinkhole looks like the whole internet being down. Anything running it should be on storage that tolerates continuous writes, and a household that will not tolerate downtime needs a second instance, since a single filtering resolver is by definition a single point of failure.
Storage endurance, not processing power, is the decision that determines how long the host survives. The documented minimums and the buying trade-offs behind them are in Pi-hole hardware requirements, and the memory and blocklist sizer gives a rough estimate of where a given list size and query volume lands.
Common mistakes
Pairing the sinkhole with a public resolver as a fallback. Adding lists until something breaks, then blaming the application. Expecting in-app or same-domain advertising to disappear. Forgetting that devices with hardcoded or encrypted DNS bypass it entirely. Running it on cheap flash storage and being surprised when it stops.
