Docs › LAN resolution

Unbound on pfSense: allow private answers

pfSense strips RFC 1918 answers for public names by default. Unlike OPNsense it does not filter the 100.64.0.0/10 range, so an overlay address needs no fix here.

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

Services ▸ DNS Resolver ▸ General Settings ▸ Custom Options

server:
private-domain: "alice.home.network"

The leading server: line is required, and omitting it makes Unbound refuse to start. Save, then Apply Changes. Because pfSense leaves 100.64.0.0/10 alone, a Tailscale name failing here has some other cause and this entry will not change it. pfSense also adds a private domain automatically for any Domain Override, so a forwarded domain needs nothing.

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