Docs › LAN resolution

Pi-hole and AdGuard Home: allow private answers

Neither strips private answers, for RFC 1918 or for the overlay range. If a name fails on a network running one of them, the cause is upstream and no change to Pi-hole or AdGuard Home will fix it.

Confirm this is the problem

Run both from the machine that cannot resolve the name.

diagnose

dig +short nas.alice.home.network @1.1.1.1
dig +short nas.alice.home.network

Result	Meaning
First returns the address, second returns nothing	Your resolver is stripping the answer. Apply the fix below.
Both return nothing	The record is missing or wrong. Nothing on the router will help.

Check the status, not only the output. A stripped answer comes back NOERROR with ANSWER: 0, never NXDOMAIN. NXDOMAIN means the record does not exist. Querying @ns1.home.network proves only that the record exists, since it bypasses both resolvers and cannot tell the two cases apart.

The fix

Nothing to change

# The resolver Pi-hole or AdGuard Home forwards to is the one
# filtering. That is usually the router, or the ISP resolver it
# uses. Apply the fix for that device instead.

Two settings look relevant and are not. Pi-hole's dns.bogusPriv and AdGuard Home's "Use private reverse DNS resolvers" both affect reverse and PTR lookups only, and have no effect on the A and AAAA records this concerns. Changing either will not help, so check the upstream resolver instead.

Substitute your own label for alice. The exception covers every name beneath it, so it is added once rather than per device.

Why this happens

Rebind protection exists to stop a hostile public name resolving to an address inside your network. Pointing your own names at your own machines is the same shape as that attack and cannot be distinguished automatically, so resolvers take an allowlist instead. Naming one domain you control is the narrowest possible exception.

← All documentation