dtoro/oikos
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

DNS Phase 4: attempted single-zone, reverted (managed zone load-bearing)

Browse Source 
Deleting the NetBird managed-zone replica broke mesh-peer DNS: the Mac
(NetBird 0.68.3) could not resolve hubris.network via the home-lab-dns
nameserver group (-> 192.168.8.2) even though it shows "Available" and the
192.168.8.0/24 route is present. Forwarding to the routed-LAN IP does not
actually serve queries on the current client. Restored the managed zone via
dns-sync.py and re-enabled the cron; resolution recovered.

Correction to Phase 2: the route fix delivered roaming-peer *service
connectivity* (the real iPhone win) but did NOT enable DNS forwarding. The
original "NetBird won't forward to Technitium for mesh peers" finding
stands; managed zone + sync are retained as load-bearing.

To finish single-source later: upgrade clients to 0.71.x, or point the
nameserver group at a mesh-native DNS IP (join CT 107 to the mesh).

Docs: dns.md + 107-dns.md corrected to reflect retained managed zone.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
authentik Default Admin
2026-06-21 15:33:33 +02:00
parent f9f2e8ab5e
commit 0ff592d237
2 changed files with 14 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
containers/107-dns.md
View File

@@ -24,14 +24,14 @@ Authoritative split-horizon DNS for `hubris.network` on the LAN/mesh, plus recur
- API: `http://192.168.8.2:5380/api/...` (token via `/api/user/login`). Zone was built via the API.
## Who points here
- **NetBird mesh peers:** resolve `hubris.network` via the `home-lab-dns` nameserver group (`→ 192.168.8.2`, applied to all peers) — now that roaming peers (`Core`) have the `192.168.8.0/24` route (fixed 2026-06-21), this forwarding path works for everyone. The **NetBird managed DNS zone** (kept in sync from this Technitium via dns-sync below) is now a redundant fallback, slated for removal in Phase 4.
- **NetBird mesh peers:** resolve `hubris.network` via the **NetBird managed DNS zone** (kept in sync from this Technitium — see dns-sync below). This is **load-bearing**, not redundant: a Phase 4 test (2026-06-21) that deleted the managed zone broke resolution for mesh peers. The `home-lab-dns` nameserver group (`→ 192.168.8.2`, applied to all peers) shows `Available` but does **not** actually serve queries on the current client (Mac 0.68.3) — forwarding to the routed-LAN IP silently returns nothing. The 2026-06-21 route fix (added `Core` → `192.168.8.0/24`) restored service *connectivity* for roaming peers but did not change DNS-forwarding behavior.
- **Homelab DHCP clients:** Technitium's own DHCP scope hands out `192.168.8.2` as the DNS server for `192.168.8.x` leases (see DHCP section below).
- **Plain LAN clients (`192.168.178.x`):** Fritz!Box DHCP still hands out Fritz!Box itself (`192.168.178.1`) as DNS, **but** the Fritz!Box now *forwards* upstream to Technitium — DNSv4 server set to `192.168.8.2` (Internet → Filter → DNS Server, 2026-06-17). So household clients get split-horizon `*.hubris.network` answers via Fritz!Box→Technitium, with **no NetBird dependency**. (This is the change that decoupled the on-prem tier from the mesh — see [dns.md](../infrastructure/dns.md) 2026-06-17.)
## dns-sync (Technitium = authoring source)
`/opt/dns-sync/sync.py` (cron `*/10`, logs `/var/log/dns-sync.log`) reconciles this zone's named A-records → the NetBird managed DNS zone via the NetBird API (`/api/dns/zones/{id}/records`). Token at `/opt/dns-sync/netbird-token` (mode 600; source of truth in sops `secrets/netbird-pat.yaml`). **Edit DNS only here**; the sync propagates to the mesh. It deletes NetBird records absent from Technitium. Tracked: [scripts/dns-sync.py](../scripts/dns-sync.py).
> **Why this exists (and why it's being retired) — corrected 2026-06-21.** The sync was built on the belief that "NetBird won't forward to Technitium for mesh peers." That was **wrong**: the `home-lab-dns` nameserver group (→ `192.168.8.2`, domain `hubris.network`) was applied to all peers, but the `192.168.8.0/24` route was distributed only to the `Services` group — roaming peers (`Core`) had no route to reach `192.168.8.2`. Adding `Core` to the route distribution fixed forwarding directly. The managed zone + this sync are now redundant and slated for removal in Phase 4. See [dns.md changelog 2026-06-21](../infrastructure/dns.md).
> **Why this exists — RETAINED (Phase 4 reverted 2026-06-21).** The managed zone is the mechanism that actually answers `hubris.network` for mesh peers. We tried to retire it (forward to Technitium instead) on the theory that a missing route was the only blocker — adding `Core` to the `192.168.8.0/24` distribution did fix roaming-peer *service connectivity*. But deleting the managed zone then broke DNS resolution for mesh peers: forwarding to `192.168.8.2` reports `Available` yet does not serve queries on the current client (Mac 0.68.3). So the original "NetBird won't forward to Technitium for mesh peers" finding stands. The managed zone + this sync are **kept**. To remove them, forwarding must first be made to actually work — candidates: upgrade clients to 0.71.x, or point the nameserver group at a **mesh-native** DNS IP (join CT 107 to the mesh) rather than the routed-LAN `192.168.8.2`. See [dns.md changelog 2026-06-21](../infrastructure/dns.md).
## DHCP

13
infrastructure/dns.md
View File

@@ -76,7 +76,18 @@ Either:
## Changelog
### 2026-06-21 — DNS single-source, Phase 2: roaming-peer forwarding fixed (root cause was a missing route, not a NetBird bug)
### 2026-06-21 — DNS single-source, Phase 4: ATTEMPTED + REVERTED — managed zone is load-bearing
Tried to collapse to a single zone by deleting the NetBird managed-zone replica (and pausing `dns-sync`). Result: **mesh-peer DNS broke.** With the managed zone gone, the Mac (NetBird 0.68.3) failed to resolve `git`/`cloud`/`nfs-export`.hubris.network via the NetBird resolver (`100.122.255.254`) — the `home-lab-dns` nameserver group (`→ 192.168.8.2`) reports `Available` but does **not** actually serve forwarded queries. Restored the managed zone via `dns-sync.py` (23 records) and re-enabled the cron; resolution recovered immediately.
**Correction to the Phase 2 entry below:** the missing route was *a* real problem (it blocked roaming-peer *connectivity* to services — the actual user-facing win), but it was **not** the whole story. DNS forwarding to the routed-LAN IP `192.168.8.2` still does not work for mesh peers, so the original "NetBird won't forward to Technitium" finding stands and the managed zone stays.
**To actually finish single-source later**, forwarding must first be made to work. Two candidates, untried:
- Upgrade NetBird clients to 0.71.x (the Mac is 0.68.3 — version skew with mgmt 0.71.3 is a known source of resolver bugs), then retest.
- Point `home-lab-dns` at a **mesh-native** DNS IP — join CT 107 to the mesh and use its `100.122.x` address instead of the routed-LAN `192.168.8.2` (the original Phase 2 hypothesis; needs a brief 107 restart for `/dev/net/tun`).
Net state after today: Phase 1 (on-prem single resolver) and Phase 2 (roaming route → iPhone reaches the homelab) stand and deliver the practical goals. The managed-zone replica + sync are **retained** as load-bearing.
### 2026-06-21 — DNS single-source, Phase 2: roaming-peer route fixed (see Phase 4 correction above — forwarding still doesn't serve queries; this fixed *connectivity*, not DNS)
The long-standing belief that "NetBird won't forward to Technitium for mesh peers" (which is *why* the managed-zone sync was built) turned out to be **wrong**. The NetBird API showed the real cause:
- The `home-lab-dns` nameserver group (→ `192.168.8.2`, match-domain `hubris.network`) was already applied to **all** peers (via the `All` group). So every peer *had* the forwarding rule.