ADR 0148: the mesh's names are resolved, not copied into every container

Answers issue 151. Copying the roster into each container made the roster part of each container's identity, so one name moving replaced every container in the mesh — and it never stopped the staleness it was for, since a copy taken at creation is stale the moment the roster moves (109, 135). A container resolves through its machine's resolver instead, and nothing is copied. Staleness stops being possible rather than detected, and a name's blast radius becomes nothing. Scoping each container to the names it binds was the close call and is rejected: it contradicts anything-calls-anything, and leaves the roster in the digest so the churn returns for a widely-bound name. Gated on issue 110 — a container on the runtime's default network has no DNS at all today. Removing the copy first reintroduces 109 and 135 silently on a live mesh. 151 stays open until the code lands; design 08's file-not-resolver passage is narrowed to the machine's own roster.
2026-09-30 00:34:30 +02:00
parent 5a3dee9e9e
commit ec42ee0846
5 changed files with 219 additions and 1 deletions
@@ -51,3 +51,19 @@ knows that is what the rule means.
  the runtime's default one? That is a stronger rule and would have prevented 109 as well.
 - What checks it? A converged bed with a container on the default network resolving a mesh name is
  the missing assertion; nothing in the resolver's own beds covers the filter.
+
+## What now depends on this (2026-09-30)
+
+This stopped being a container-DNS inconvenience.
+[ADR 0148](../../02-DECISIONS/0148-the-meshs-names-are-resolved-not-copied-into-containers.md) decides
+that a container resolves the mesh's names rather than being given a copy of them, which is what stops
+one name moving from replacing every container in the mesh
+([issue 151](../151-a-new-name-recreates-every-container-in-the-mesh/00-report.md)) and what makes a
+stale address impossible rather than merely noticed
+([issues 109](../109-a-container-keeps-the-address-it-was-made-with/00-report.md)
+and [135](../135-a-containers-mesh-names-are-not-compared/00-report.md)).
+
+**That decision cannot land until this one does**, and not partly: a container on the runtime's default
+network is the case with no DNS at all, and it is the case the mesh's own forge runs in. Two of four
+machines also bind the resolver to loopback only, so the runtime hands their containers a public
+resolver. Both halves are this issue.
@@ -75,3 +75,20 @@ the list. 152 removed the false reasons; the question below is still open.
 Keep 135's guarantee (no container runs with a stale address) without making the roster part of every
 container's identity — e.g. resolve mesh names through a resolver the container asks at lookup time
 rather than baked entries, or scope each container's entries to the names it actually binds.
+
+## Answered (2026-09-30): the first of those two
+
+[ADR 0148](../../02-DECISIONS/0148-the-meshs-names-are-resolved-not-copied-into-containers.md) takes
+the resolver, not the scoping. Scoping was the close call and was rejected for contradicting the
+standing intent that anything on the mesh can call anything on it: it would make a name reachable only
+where the mesh was told in advance it would be wanted, and it would leave the roster in the digest, so
+the churn returns whenever a widely-bound name moves.
+
+Resolving at lookup time makes staleness impossible rather than detected — 109 and 135 stop being bugs
+that were fixed and become a shape that does not exist — and makes a name's blast radius nothing.
+
+**This record stays open**, because the record answers it and the code does not. Nothing may stop
+copying names until a container can reach the resolver from any of the runtime's networks
+([issue 110](../110-a-container-on-the-runtimes-own-network-cannot-reach-the-resolver/00-report.md)),
+which it cannot on two of four machines today. Removing the copy first reintroduces 109 and 135
+silently, on a live mesh, which is how both were found. The order is in the record.