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.
53 lines
2.6 KiB
Markdown
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.
|