Issue 112: diagnose — the predecessor's own DNS config already names the carried peers #101

Merged
jschoubben merged 3 commits from issue/112-diagnosis into main 2026-09-24 12:49:51 +00:00
2 changed files with 12 additions and 7 deletions
Showing only changes of commit 75c104c355 - Show all commits
@@ -1,7 +1,7 @@
---
status: diagnosing
opened: 2026-09-24
located-in: [mesh-controller internal/catalogue, mesh-controller cmd/mesh-controller, mesh-catalog modules/dnsmasq]
located-in: [mesh-controller internal/inventory, mesh-controller internal/catalogue, mesh-controller cmd/mesh-controller, mesh-catalog modules/dnsmasq]
fixed-by:
amended-design:
---
@@ -54,12 +54,17 @@ inventing a fact under time pressure — it is the predecessor's own record, cur
correctly serving these three names for six days without correction. Recording it is transcription,
not assertion.
**located-in, tentatively:** `mesh-controller internal/catalogue` (where a carried peer's fact would
need a name field) and `cmd/mesh-controller` (a command to set it — nothing today lets an operator
attach a name to a carried-tunnel-peer record; `node add` is for enrolling nodes, not naming
peers). `mesh-catalog modules/dnsmasq` would then need to emit an `address=` wildcard for a *named
carried peer* the same way it does for a node, which the module's own generation code does not
distinguish today.
**located-in, tentatively:** `mesh-controller internal/inventory` (where a carried peer's record
lives today — `CarriedPeer`/`TunnelPeer` in `tunnel.go` carry a public key and an address but no
name field) and `cmd/mesh-controller` (a command to set it — nothing today lets an operator attach
a name to a carried-tunnel-peer record; `node add` is for enrolling nodes, not naming peers, and
`node public-domain <name> <d>` is the closest existing shape to model a new verb on). Separately,
`mesh-controller internal/catalogue` (`facts.go`'s `nodeZones`) would then need to emit an
`address=` wildcard for a *named carried peer* the same way it does for a node — it renders only
from the mesh's `addresses` map today, keyed by node name, and does not distinguish a named carried
peer from an unnamed one. `mesh-catalog modules/dnsmasq` itself needs no change: it already
restarts on the `node-zones` fact and would pick up the new wildcard the moment `internal/catalogue`
emits it.
## What is still open