ADR-0008 moves DNS off the gateway, which adds a second and quieter way for the house to lose the internet

[Gerrrt]

Rewritten after checking what the DHCP scopes actually hand out. The original framing — a filtering resolver already sitting in the critical path — was wrong, and the real issue is narrower and points forward rather than at the current estate.

What the documentation says today

Gerrrt/Lemmiwinks/infrastructure/dhcp_dns_overview.md, DHCP options:

• Default gateway per VLAN
• DNS server: pfSense
• NTP: pfSense

and Gerrrt/Lemmiwinks/network/dhcp_dns_architecture.md:

Internal DNS is handled by

pfSense Unbound DNS Resolver

External DNS

• Cloudflare (primary)
• Google (secondary)

The distinction that matters

Cloudflare and Google are Unbound's upstream forwarders, not the clients' secondary resolver. Clients get exactly one resolver: pfSense. The redundancy is real but it sits on the wrong side of the resolver to help here.

That makes today's arrangement fine for this failure mode, which is why the original issue was misdirected: DNS lives on the same box as the default gateway, so "DNS is down" and "the gateway is down" are the same event. It adds no independent point of failure, and the family's internet_is_down_what_do_we_do.md correctly walks toward pfSense.

Pi-hole (Gerrrt/Lemmiwinks/services/pi_hole.md) doesn't appear to be in the client path either; the same doc lists "Block-list support (optional)" under pfSense's own features.

What ADR-0008 threatened to change

ADR-0008 puts AdGuard Home on the Winterfell mini PC. Had that become the client-facing resolver, it would have decoupled DNS from the gateway and introduced a new failure:

• the mini PC dies, or its container stops, or it's mid-reboot for updates
• pfSense is healthy, modem lights green, WAN up, every cable fine
• and nothing in the house resolves a name

Every device breaks at once, so it reads as "the internet is down" — but the family's nine-step runbook walks modem → switch → pfSense → eero and comes back green at every step, with no branch for "everything is up and it still doesn't work."

Resolved by #125

#125 chose Option C: clients keep being handed pfSense as their only resolver, and Unbound forwards to AdGuard for filtering, with the public upstreams also listed so a dead AdGuard drops out and resolution continues unfiltered.

That removes the failure mode this issue was opened for. DNS stays co-located with the gateway from the client's point of view, so "DNS is down" and "the gateway is down" remain the same event, and losing AdGuard costs filtering rather than connectivity.

What's left here

Small, and no longer blocking:

• The family-facing runbook still deserves one line for the case where filtering is down but the internet works — likely presenting as ads reappearing rather than as an outage. That's a "mention it to whoever maintains this" note, not a troubleshooting branch.
• Losing AdGuard should be visible to monitoring, since by design it's now silent to everyone in the house. It fails in exactly the way Detect Suricata being dead — a quiet IDS and a stopped one look identical #90 describes for Suricata: a filtering service that's dead and one that's merely quiet look identical from outside.

Related: #122, the same settle-before-building argument for the rest of that tier.

Still unverified

The live config isn't checkable from the repo — make backup-firewall output is gitignored (Makefile:266-270) and stacks/ holds only observability. Everything above is from Lemmiwinks docs that are nine months stale (#5 there) and self-inconsistent on nearby details: one page has Oracle and Wiki.js both on 10.0.99.30, while services/wiki_js.md puts the wiki on 10.0.99.20.

Confirming what's actually handed out today is still worth doing before implementing #125, since it assumes the documented baseline:

• pfSense UI → Services → DHCP Server → each VLAN → the DNS servers fields
• from the config: make backup-firewall, then read the <dnsserver> entries inside each <dhcpd> scope in the XML
• from a client, which is the ground truth: resolvectl status on Linux, scutil --dns on macOS, ipconfig /all on Windows