Fix a Pi-hole Block Without Disabling Pi-hole

Fix a Pi-hole application block by identifying the exact matching rule, changing every resolver that can answer, clearing cached responses, and allowing only the hostname the application needs. Disabling filtering is not diagnosis.

The browser failure was only the symptom

I was connecting Hack Your World to AdSense when the setup flow stopped working. Refreshing the page was tempting because the failure appeared in a browser, but a browser error can sit several layers above the actual fault. The local DNS filter was answering the lookup with a block address, so there was no useful web connection for the browser to retry.

The important test was not “does AdSense work somewhere?” It was “what answer does each DNS resolver give this client?” My network has a primary and a secondary resolver. The primary returned public IPv4 and IPv6 records. The secondary returned Pi-hole’s blocking answers: 0.0.0.0 for A and :: for AAAA.

That split explained why the problem could feel inconsistent. A client may have more than one DNS server configured, and the label “secondary” does not guarantee that it will sit idle until the primary is dead. Different clients and cached lookups can expose different answers. One correct resolver and one blocking resolver is still a broken configuration.

I asked Pi-hole which rule matched

I checked the blocked name before changing anything:

pihole query adsense.google.com

The query showed that a subscribed blocklist matched adsense.google.com. There was no exact allowlist entry on the failing resolver. That distinction mattered. I wanted to make the administrative destination reachable; I did not want to suspend filtering for the network or guess at a list of related Google domains.

Pi-hole documents exact allowlist entries as the highest-priority domain rule, ahead of subscribed denylist entries. Its command-line allow operation adds the domain and reloads the DNS service. That makes the smallest useful change straightforward:

pihole allow adsense.google.com

I ran that command inside the Pi-hole container on the resolver that was still blocking it. The first resolver already had the same exact entry. Afterward, both returned public A and AAAA answers.

The fix belongs on every resolver that can answer

Adding the rule to one Pi-hole had created a configuration that looked finished from one test point. It was not finished from the network’s point of view. If two resolvers can answer the same clients, both need the intended policy.

I verified each one explicitly instead of relying on the operating system’s selected resolver:

dig @<primary-dns> adsense.google.com A
dig @<primary-dns> adsense.google.com AAAA
dig @<secondary-dns> adsense.google.com A
dig @<secondary-dns> adsense.google.com AAAA

The exact addresses are not the point and can change. The distinction is whether each answer contains a routable public address or a blocking response such as 0.0.0.0 or ::. I keep private hostnames and addresses out of screenshots and articles because they add no value to the repair.

For a single Pi-hole, one direct query is enough. For redundant DNS, the test matrix grows with the number of servers. I now treat a DNS policy change like any other replicated configuration: apply it everywhere that serves the policy, and verify every instance independently.

Why a refresh can still look broken

DNS answers can remain in more than one cache. Pi-hole may have reloaded its rules while the operating system, browser, or an application still holds the earlier block answer. I test the resolver directly first because it separates server state from client cache state.

If direct queries are correct but the page remains broken, I close the affected browser tab and clear the client DNS cache using the operating system’s normal method. I do not start by restarting every network service. A broad restart destroys evidence and makes it harder to know which action actually repaired the path.

IPv6 deserves its own check. An A lookup can be correct while an AAAA lookup still returns ::. A browser can prefer IPv6, so testing only IPv4 may leave half the failure intact.

What I deliberately did not allow

The exception is exactly adsense.google.com. I did not create a wildcard for Google, disable a blocklist, pause Pi-hole, or add every hostname visible in the browser’s network panel. The purpose was to reach the AdSense account and site-setup interface from my own network.

This also does not force advertising through someone else’s filter. Hack Your World can request an ad from Google’s delivery infrastructure when ads are enabled, and a visitor can still block that request locally. My administrative allowlist and a visitor’s DNS policy are separate decisions.

A narrow exception is easier to review later. The domain says why it exists, the matching rule is exact, and removal is equally specific:

pihole allow remove adsense.google.com

If AdSense changes its administration host in the future, I would diagnose that host from fresh DNS evidence. I would not pre-authorize a family of domains in anticipation.

What the allowlist changed

This distinction matters because “AdSense works now” would overstate the result. The account can still be in review, payment identity can still require owner input, and Google’s crawler can still take time to observe a valid ads.txt file. The DNS exception only repaired access to one administration hostname from my network.

The checklist I will use next time

1. Copy the exact failing hostname from the browser or application error path.
2. Query every configured resolver for both A and AAAA records.
3. Use pihole query <hostname> to identify the matching list or rule.
4. Add one exact allowlist entry only when the destination is expected and necessary.
5. Apply the same intended policy to every resolver that serves those clients.
6. Repeat the direct DNS tests before touching client caches.
7. Record what the change proves and keep account approval, crawler status, and ad delivery as separate checks.

Pi-hole is infrastructure because its state decides whether other systems can be reached, and redundant infrastructure is only reliable when its policy is consistent. The safest repair here was also the smallest: one domain, two resolvers, four direct DNS checks.

Pi-hole’s official documentation covers the allowlist command, domain-rule priority, and query command. Hack Your World’s advertising and data-use disclosures are on the privacy page.

Disclosure: This came from a live failure on my two Pi-hole resolvers. Private addresses and hostnames are omitted.