Issue 198: the home network's DNS server ran outside the mesh, and its filter closed it

2026-10-02 12:22:31 +02:00
parent 5c993c09b7
commit 426f741ad0
1 changed files with 71 additions and 0 deletions
@@ -0,0 +1,71 @@
 ---
 status: resolved
 opened: 2026-10-02
 located-in: [mesh-catalog modules/dnsmasq (listens on loopback and the machine's mesh address only), the home-server's DNS (a predecessor's dnsmasq configuration the mesh did not own), the home network's DHCP (hands out the home-server as every device's DNS)]
 fixed-by: mesh-catalog PR 214 (dnsmasq listens on addresses from a setting; docker's file takes no settings), mesh-controller PR 210 (the settings verb), mesh-catalog PR 215 (unifi network DNS tools), live 2026-10-02
 amended-design: []
 ---
 # 198 — The home network's DNS server ran outside the mesh, and the mesh's filter closed it
 ## What was observed
 Every phone on the home Wi-Fi had no internet, while a laptop on the same Wi-Fi did. The router's
 DHCP hands every device the home-server's LAN address as its DNS server. The home-server's DNS daemon
 was listening on that address, and every query to it timed out. The router itself answered the same
 query at once. The laptop worked because it resolves through its own local resolver, not through the
 server DHCP names.
 ## Why it happened
 The DNS daemon on the home-server was not the mesh's. It ran under a configuration file a predecessor
 generated, listening on loopback, the mesh address and the LAN address. The mesh's `dnsmasq` module was
 assigned to the other three machines and not to this one, so no module on the home-server declared
 port 53. Its filter opens only what a module declares, so DNS from the LAN was dropped. It started when
 the home-server applied the filter this morning, after nine hours of applying nothing
 ([issue 194](../194-the-hosts-own-former-archive-stops-every-apply/00-report.md)).
 Nothing said so. The daemon reported running, the filter applied cleanly, and the mesh had no record
 that the home network depended on a service it did not know.
 ## Why it matters
 **A service the mesh does not know is closed by the mesh's filter, by design, and nothing asks whether
 something depends on it.** That is the right default for an unknown port. It is the wrong outcome for
 the one service a whole network was told to use. The gap is that a machine can run something
 important outside the mesh with nothing to show it.
 **The mesh's `dnsmasq` could not have served the LAN either.** It listened on loopback and the mesh
 address only. The reach of its DNS endpoints opens the filter, but the daemon would not have been
 listening on the LAN address anyway.
 ## Open questions
 - Should a machine report the listening services the mesh does not own, the way it reports the links
  that face outside? This one would have been visible before the filter closed it.
 - The LAN address the home-server answers on is now a setting, beside the reach that opens the filter.
  Two statements that must agree. Should reach `public` on a DNS endpoint imply listening beyond the
  mesh?
 ## Resolved (2026-10-02)
 The home network was pointed at the gateway for DNS while the fix was built, which got the phones back
 within minutes. Then:
 - the mesh's `dnsmasq` takes the addresses it listens on beside the machine's from a setting, with
  loopback as the mesh-wide default, so no other machine changed;
 - the home-server's layer adds its LAN address, and its DNS endpoints' reach is `public`. The router
  forwards no DNS, so that means the LAN;
 - the module and its sibling `resolv-conf` were assigned to the home-server, replacing the
  predecessor's daemon and configuration, which were kept aside;
 - the home network was pointed back at the home-server, through a new `unifi` tool.
 Checked live: from another machine on the LAN, public names and mesh names both resolve through the
 home-server's LAN address, and the mesh and the machine itself resolve as before.
 **One fault found on the way, and caught before it reached any machine.** A module's settings are
 merged into every mergeable file the module owns. The first attempt therefore put the new setting into
 docker's `daemon.json` as well as into dnsmasq's config, and dockerd refuses keys it does not know. The
 plan showed it before any push. The change was reverted and redone with docker's file declared to take
 no settings. The general fault, a module's settings reaching files they were not meant for, is still
 there for any module with more than one file.