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

2.6 KiB

status, opened, located-in, fixed-by, amended-design
status opened located-in fixed-by amended-design
resolved 2026-09-24
mesh-controller cmd/mesh-controller/plan.go
mesh-controller internal/catalogue/facts.go
mesh-controller — tell the resolver the machines, not the names the mesh merely serves

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) — 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.

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.