What a Pi-hole DNS Sinkhole Can and Cannot Block

A DNS sinkhole, also called black hole DNS, is a resolver that answers lookups for listed domains with a dead-end reply instead of the real address. Pi-hole is one. It can block any hostname a device resolves through it; it cannot block content served from an allowed hostname, connections to literal IP addresses, or devices whose DNS bypasses it.

When a device asks for a hostname matched by Pi-hole’s deny rules or blocklists, Pi-hole returns a configured blocking response instead of the 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.

Black hole DNS, null routes and DNSBLs are different things

In networking, a black hole is anywhere traffic is discarded without telling the sender. Several mechanisms carry the name, and only one of them is what Pi-hole does:

Wikipedia’s sinkhole entry lists ad blocking and disrupting botnet coordination, citing WannaCry and Avalanche, among its uses. Either way the sinkhole acts only when a name is looked up. A null route drops traffic to an address however the client found it, so literal-IP connections need a router or firewall rule, not another blocklist.

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.

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:

1. Confirm that the client received the intended resolver addresses. Check the application’s DNS settings as well as the operating system’s.
2. 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.
3. 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.
4. 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.
5. 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.

What does “Blocked (external, NXRA)” mean in Pi-hole?

Blocked (external, NXRA) means the block did not come from Pi-hole’s lists. The upstream resolver Pi-hole forwarded the query to answered NXDOMAIN (“no such domain”) with the Recursion Available (RA) bit unset, which FTL treats as an upstream block. Pi-hole logs it as query status 8 and offers no Allow button, since there is no local rule to override.

RFC 1035 defines RA as the bit that “denotes whether recursive query support is available in the name server”, so a working recursive resolver sets it even for a name that does not exist. Quad9 clears it on blocklist hits, as a Quad9 post in an AdGuard Home discussion stated in August 2025. Quad9’s FAQ shows both cases returning status: NXDOMAIN:

$ dig @9.9.9.9 isitblocked.org          # blocked by Quad9
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

$ dig @9.9.9.9 sfaisofnadgre.odafds     # name does not exist
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

NXRA is one of four upstream-block signals. The query database documentation gives the status IDs and the web interface code the labels:

In a September 2025 forum thread on FTL v6.2.3, the log read blocked upstream with NXRA address www.youtube.com is 0.0.0.0: the client got 0.0.0.0, not the upstream’s NXDOMAIN. FTL caches such blocks for dns.cache.upstreamBlockedTTL, 86400 seconds (one day) by default per the configuration reference, before asking upstream again.

Trace and fix an NXRA block

1. Rule out your own lists. pihole -q example.com searches your allowlist, denylist, wildcards and subscribed lists, per the command reference. No match plus an external status means the upstream refused the name.
2. Query each configured upstream directly, such as dig @9.9.9.9 example.com. The one answering NXDOMAIN without ra in its flags is doing the filtering. Upstreams are set during installation and editable later.
3. Decide whether you want that filter. With Quad9’s 9.9.9.9, chosen for threat blocking, the entry is the service working. For a false positive, switch upstream; Quad9’s no-threat-blocking service is 9.9.9.10 and 149.112.112.10. A Pi-hole allow rule will not help: per a 2023 forum reply, external means the upstream is blocking, and Pi-hole cannot change that.
4. Clear the cached block with pihole reloaddns, which flushes FTL’s DNS cache. To stop caching upstream blocks entirely, run sudo pihole-FTL --config dns.cache.upstreamBlockedTTL 0.
5. If every uncached lookup turns NXRA, an upstream is broken rather than filtering. In the 2025 thread, with OpenDNS and dns0.eu as upstreams, even www.youtube.com was hit, and one reply noted that upstream servers “shouldn’t reply with NXDOMAIN and no RA bit set”. Remove upstreams one at a time and test again.

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.

FAQ

is a dns black hole the same as a null route

No. A DNS black hole, or sinkhole, refuses to resolve listed hostnames, so it only affects traffic that starts with a lookup. A null route is a routing entry that drops packets sent to an IP address, whatever name the client used. Pi-hole is the first kind, never the second.

can i allowlist a blocked (external) domain in pi-hole

Not in Pi-hole. An external status means the upstream resolver refused the name, so the web interface shows no Allow button and a local allow rule cannot change the answer. Switch to an unfiltered upstream or adjust the provider’s settings, then run pihole reloaddns so the cached block does not linger.

what does nxdomain mean in the pi-hole query log

NXDOMAIN is DNS response code 3, “Name Error”: the queried name does not exist. With the RA flag set it is an ordinary reply for a missing or mistyped name. Pi-hole returns NXDOMAIN itself for the Firefox canary domain and for blocked names in NXDOMAIN blocking mode, and treats an upstream NXDOMAIN without RA as an external block.

does pi-hole block ads inside apps

Yes, when the app fetches ads from hostnames used only for advertising and resolves them through Pi-hole. It fails when the app serves ads from the same hostname as its content, connects to literal IP addresses, or uses its own hardcoded or encrypted DNS resolver, because Pi-hole then never sees a separate lookup it can refuse.