jschoubben
6a56738d7b
Checked why ADR 0104's forward-to-predecessor shape doesn't transfer to the resolver the way it did the proxy: DNS is one process on one port, and assigning the mesh's dnsmasq module replaces it in place, so there is no predecessor process left standing to forward to. But /etc/dnsmasq.d/hal-dns.conf's static address= lines for ace/shanks/g14 match the mesh's own carried-peer addresses from overlay show exactly. The name a carried peer needs isn't a guess the operator has to make under pressure — it's a transcription of a record the predecessor already has and has been correctly serving for six days. Located in mesh-controller (no way to attach a name to a carried peer today) and the dnsmasq module (doesn't emit a wildcard for a named-but-uncarried peer). Not implemented.
2.7 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |||
|---|---|---|---|---|---|---|---|
| diagnosing | 2026-09-24 |
|
112 — Adopting a tunnel gives the mesh the peers' addresses but not their names
What was observed
On the control-node, 2026-09-24, reading what the resolver would answer before it was assigned.
The predecessor's resolver answers for four machines — the hub and the three that reach it over the tunnel. The mesh's would have answered for one: itself. The other three are carried peers of the tunnel the hub took over (ADR 0105) — the mesh holds an address for each, and keeps it, and has no name for any of them, because a name comes from enrolling and they have not enrolled.
Taking the resolver in that state replaces a file that resolves four machines with one that resolves one, and — because the resolver is told the mesh's suffix is its own and forwards nothing under it — the other three stop resolving rather than falling through. Everything on the machine that reaches another by name breaks at once: the predecessor's own agents, its pipeline, anything an operator typed.
Why it matters beyond this instance
Adoption was designed so that what the mesh does not know yet, it leaves alone. The tunnel is the first place the mesh takes over something whose content is knowledge the predecessor has — three machines exist, and these are their names — and it takes the addresses without the names. Nothing says so; the mesh reads as complete.
This is an ordering rule the migration did not have: a name the predecessor answers for must keep resolving until the machine behind it is a node. It applies to the resolver first and to anything else derived from "the machines the mesh knows" while the mesh knows fewer than the machine does.
Open questions
- Should a carried peer be nameable — the operator saying which machine a carried address is, before it enrols — so the resolver can answer for it in the meantime? The mesh would be recording a name it cannot verify.
- Or should the resolver simply not be taken until every carried peer has enrolled, stated as a refusal rather than a note in a runbook?
- Or should the mesh's resolver, while any peer is carried, forward the suffix it cannot answer to the resolver it replaced — which is the adapter shape (ADR 0104) applied to names instead of routes?
- What checks it? Nothing compares what the predecessor's resolver answers with what the mesh's would.