Issues 111 and 112: the resolver was told the wrong set of names, twice over #98

2026-09-23T23:32:36Z

jschoubben commented

2026-09-23 23:32:36 +00:00

Both found by composing the resolver's first assignment on the control-node and reading the plan before pushing it. Nothing was applied; the module was unassigned and the machine left as it was.

111 — resolved. The control plane hands a resolution one map of names holding two kinds: the machines, and every name the mesh was told to route. The resolver's zones were given both, so two module public names appeared as machines with the mesh's suffix appended. It matters because of the line above them — told the suffix is its own, the resolver answers authoritatively for everything under it and forwards none of it, so invented names stand beside the real ones looking as real. Fixed in mesh-controller: the two sets are carried separately and each fact is handed the one it is true of. Worth noting the conversion was reviewed and its own tests passed — they were written with a map of machines, which is the shape the composer's comment assumed.

112 — open, and it is an ordering rule the migration did not have. The predecessor's resolver answers for four machines; the mesh's would answer for one. The other three are carried peers of the adopted tunnel: the mesh holds an address for each and has no name for any, because a name comes from enrolling. Taking the resolver in that state stops three machines resolving rather than falling through, and everything on the machine that reaches another by name breaks at once. The tunnel is the first thing the mesh took over whose content is knowledge the predecessor has, and it took the addresses without the names. Asks whether a carried peer should be nameable, whether the resolver should refuse to be taken while any peer is carried, or whether it should forward the suffix it cannot answer to the resolver it replaced — ADR 0104's adapter shape applied to names instead of routes.

Both found by composing the resolver's first assignment on the control-node and **reading the plan before pushing it**. Nothing was applied; the module was unassigned and the machine left as it was. **111 — resolved.** The control plane hands a resolution one map of names holding two kinds: the machines, and every name the mesh was told to route. The resolver's zones were given both, so two module public names appeared as machines with the mesh's suffix appended. It matters because of the line above them — told the suffix is its own, the resolver answers authoritatively for everything under it and forwards none of it, so invented names stand beside the real ones looking as real. Fixed in mesh-controller: the two sets are carried separately and each fact is handed the one it is true of. Worth noting the conversion was reviewed and its own tests passed — they were written with a map of machines, which is the shape the composer's comment assumed. **112 — open, and it is an ordering rule the migration did not have.** The predecessor's resolver answers for four machines; the mesh's would answer for one. The other three are carried peers of the adopted tunnel: the mesh holds an address for each and has no name for any, because a name comes from enrolling. Taking the resolver in that state stops three machines resolving rather than falling through, and everything on the machine that reaches another by name breaks at once. The tunnel is the first thing the mesh took over whose content is *knowledge the predecessor has*, and it took the addresses without the names. Asks whether a carried peer should be nameable, whether the resolver should refuse to be taken while any peer is carried, or whether it should forward the suffix it cannot answer to the resolver it replaced — ADR 0104's adapter shape applied to names instead of routes.

jschoubben added 1 commit 2026-09-23 23:32:36 +00:00

Issues 111 and 112: the resolver was told the wrong set of names, twice over f704e2ca64

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.

jschoubben merged commit 36aa722c2a into main

2026-09-23 23:32:42 +00:00

jschoubben deleted branch issues/111-112-the-resolver-was-told-the-wrong-names

2026-09-23 23:32:42 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#98