Skip to content

Add ADR-0010: keep the resolver on the gateway and filter behind it - #127

Merged
Gerrrt merged 1 commit into
mainfrom
claude/family-knowledge-center-1mysh4
Aug 24, 2026
Merged

Add ADR-0010: keep the resolver on the gateway and filter behind it#127
Gerrrt merged 1 commit into
mainfrom
claude/family-knowledge-center-1mysh4

Conversation

@Gerrrt

@Gerrrt Gerrrt commented Aug 24, 2026

Copy link
Copy Markdown
Owner

What changed

Adds docs/adr/0010-keep-the-resolver-on-the-gateway.md, recording the decision that pfSense stays the only DHCP-advertised resolver and Unbound forwards to AdGuard Home for filtering. Nothing in the running lab changes — the AdGuard host does not exist yet, and this fixes the topology before it is built.

Why

ADR-0008 places AdGuard Home on the Winterfell mini PC but does not say how clients reach it, and that second question carries the risk. Making it the client-facing resolver would decouple DNS from the default gateway and give the household an independent way to lose name resolution — presenting as a total outage while every component the family runbook checks is healthy.

Closes #125. Related: #123 (the family-facing failure mode this removes), #126 (the detection requirement it creates), #122 (the same settle-before-building argument for the rest of ADR-0008's tier).

The ADR also records why the two obvious alternatives were rejected: stub resolvers do not fail over cleanly between advertised servers, so a DHCP secondary leaks filtering whenever the primary is merely slow rather than dead, and both variants would route low-trust VLAN DNS into the sensitive tier against ADR-0008's own reasoning.

Accepted costs are written down rather than glossed: per-client attribution is lost, and the filter now fails silently.

Also corrects the ADR count in the README, which read 8 against 9 files before this change.

Blast radius

Documentation only. No configuration, no manifest, no runtime change.

  • No change to network segmentation or firewall rules
  • No new port published to a VLAN that could not already reach the service
  • No credential added outside secrets/*.sops.yaml

Worth noting the ADR's own conclusion here: implementing it later adds no inter-VLAN rule, leaving the count at the five ADR-0008 established. The rejected alternatives would each have added one.

Verification

  • make validate passes — via CI, all three jobs green on 88049e5: Lint, Validate configs, Secret scan. It could not be run in full locally (yamllint: command not found in the authoring environment, which stops make lint before the Markdown step); CI has since run the complete target, so that gap was environmental rather than a real one.
  • markdownlint-cli2 run directly against the repo's .markdownlint-cli2.yaml: Summary: 0 issues in 0 files across all 32 Markdown files. Confirmed independently by CI's Lint job.
  • Deployed to the lab and confirmed working — not applicable; no deployable change, and the AdGuard host is not built.
  • Docs updated — the ADR is the change; README ADR count corrected alongside it.

Worth a reviewer's eye on one judgement call rather than the prose: the forwarder list deliberately keeps the public upstreams alongside AdGuard, so a dead filter degrades to unfiltered resolution instead of none. That does let Unbound's round-trip-time selection send the occasional query past the filter while AdGuard is healthy. The ADR argues the leak is small because locality decides it — sub-millisecond on the LAN against ten to twenty milliseconds to Cloudflare — but it is a real trade and the alternative reading is defensible.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Vt47Sx4BTo6kmizmV31Fnn

ADR-0008 places AdGuard Home on the Winterfell mini PC but does not say
how clients reach it. Making it the client-facing resolver would decouple
DNS from the default gateway and give the household an independent way to
lose name resolution — one that presents as a total outage while every
component the family runbook checks is healthy.

Records the decision to keep pfSense as the only DHCP-advertised resolver
and have Unbound forward to AdGuard, with the public upstreams left in the
forwarder list so a dead filter costs filtering rather than connectivity.

Rejects advertising AdGuard directly, alone or as a DHCP primary: stub
resolvers do not fail over cleanly between advertised servers, so a
secondary leaks filtering whenever the primary is merely slow, and both
variants would route low-trust VLAN DNS into the sensitive tier against
ADR-0008's own reasoning.

Accepted costs are recorded: per-client attribution is lost, and the
filter now fails silently, which needs a probe that queries AdGuard
directly rather than through the fallback.

Also corrects the ADR count in the README, which read 8 against 9 files
before this change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Vt47Sx4BTo6kmizmV31Fnn
@Gerrrt
Gerrrt merged commit 3b3e174 into main Aug 24, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

pfSense stays the only advertised resolver; Unbound forwards to AdGuard Home

2 participants