Files
hq/04-ISSUES/111-the-resolver-is-told-names-the-mesh-serves-not-only-machines/00-report.md
T
jschoubben f704e2ca64 Issues 111 and 112: the resolver was told the wrong set of names, twice over
111, resolved: the map the control plane hands a resolution holds the machines and the
names the mesh merely serves, and the resolver's zones were given both — inventing names
under a suffix it answers authoritatively for. 112, open: adopting a tunnel gives the mesh
the peers' addresses and none of their names, so taking the resolver before they enrol
stops three machines resolving at all.

Both found by reading the plan before pushing it.
2026-09-24 01:32:04 +02:00

53 lines
2.6 KiB
Markdown

---
status: resolved
opened: 2026-09-24
located-in: [mesh-controller cmd/mesh-controller/plan.go, mesh-controller internal/catalogue/facts.go]
fixed-by: mesh-controller — tell the resolver the machines, not the names the mesh merely serves
amended-design:
---
# 111 — The resolver is told every name the mesh serves, not only the machines
## What was observed
Composing the resolver's first assignment on the control-node, 2026-09-24, and reading the plan
before pushing it. The file the mesh would have handed the resolver:
```
local=/internal/
address=/<a routed name>.internal/<the hub>
address=/<the node>.internal/<the hub>
address=/<another routed name>.internal/<the hub>
```
Two of the three are not machines. They are names the mesh was **told to serve** — a module's public
name, resolved mesh-wide so that a container reaching it finds the proxy serving it
([ADR 0066](../../02-DECISIONS/0066-public-routing-is-name-agnostic.md)) — with the
mesh's own suffix appended to each, producing a name nobody will ever ask for.
The control plane hands a resolution one map of names, and it holds both kinds. A container's hosts
file wants all of it. The resolver's zones want only the machines, and the difference matters
because of the line above them: told that the mesh's suffix is its own, the resolver answers
authoritatively for everything under it and forwards none of it. So the invented names sit beside
the real ones looking exactly as real, and a fourth is absent —
[issue 112](../112-adopting-a-tunnel-gives-the-mesh-addresses-without-names/00-report.md).
Nothing was pushed. The module was unassigned and the machine left as it was.
## Why it matters beyond this instance
The two sets are not the same and the mesh had one word for both. Every fact the mesh computes about
"the names" now has to say which it means, and the one that leaks is the one that is authoritative:
a resolver that answers for a name it invented cannot be asked again.
It is also a near miss of the kind worth writing down. The conversion was reviewed, its own tests
passed, and the fault was invisible in them because they were written with a map of machines — the
shape the composer's own comment assumed. It appeared the first time the composer met a live mesh
that also serves routed names, and only because the plan was read before it was pushed.
## What it is now
The control plane carries the two sets separately — every name it serves, and the machines — and
each fact is handed the one it is true of. The hosts file keeps every name; the resolver's zones take
the machines. A test pins both halves together, so neither can drift into the other again.