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.
52 lines
2.7 KiB
Markdown
52 lines
2.7 KiB
Markdown
---
|
|
status: diagnosing
|
|
opened: 2026-09-24
|
|
located-in: [mesh-controller internal/catalogue, mesh-controller cmd/mesh-controller, mesh-catalog modules/dnsmasq]
|
|
fixed-by:
|
|
amended-design:
|
|
---
|
|
|
|
# 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](../../02-DECISIONS/0105-the-mesh-adopts-the-predecessors-tunnel-in-place.md)) — 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](../../02-DECISIONS/0104-a-provision-may-be-answered-by-an-adapter-to-the-predecessor.md))
|
|
applied to names instead of routes?
|
|
- What checks it? Nothing compares what the predecessor's resolver answers with what the mesh's
|
|
would.
|