ADR 0194: the mesh has one resolver, and every node asks it for the mesh's names

Every resolution fault found on 2026-10-03 was a per-node copy disagreeing with the truth: a hosts
file read once, an operator's old line beside the mesh's, a node's resolver lent to a LAN. Every
tunnel already converges on one node. Retires node-dns-resolver for a mesh-scoped mesh-resolver;
nodes route only the mesh's suffix to it. Narrows 0121; amends connectivity §2 and the seats.

03-DESIGN/01-to-be/08-connectivity.md

@@ -10,6 +10,7 @@ code:
   - mesh-host internal/apply (the service that reflects a rule set)
 updated: 2026-10-03
 decisions:
+  - 02-DECISIONS/0194-the-mesh-has-one-resolver-and-every-node-asks-it-for-the-meshs-names.md
   - 02-DECISIONS/0191-the-meshs-resolver-holds-only-the-meshs-own-names.md
   - 02-DECISIONS/0180-the-found-front-end-is-uninstalled-once-a-machine-is-converged.md
   - 02-DECISIONS/0170-the-firewall-seat-serves-its-verbs.md
@@ -290,8 +291,9 @@ expensively enough to be worth restating:
 - **A node must not pin its own public name locally.** The duplicate record breaks resolution of
   that name for everything else that needs it.
 
-**What the host receives:** the resolver's configuration, as files, listing every peer's internal
-name and overlay address.
+**What the host receives:** what to ask, not what to answer. The mesh has **one resolver**, holding
+every node's internal domain; a node routes the mesh's suffix to it and every other name to public
+resolvers ([ADR 0194](../../02-DECISIONS/0194-the-mesh-has-one-resolver-and-every-node-asks-it-for-the-meshs-names.md)).
 
 **What goes away:** the `/etc/hosts` floor. It exists because a node had to reach the mesh
 database before its own DNS existed; with [ADR 0004](../../02-DECISIONS/0004-a-node-and-how-it-joins.md)
@@ -349,6 +351,28 @@ not a list of containers.
 somebody starts by hand is not the mesh's to configure, and reaching into every container on a
 machine — declared or not — is what a nameserver in `resolv.conf` would be for.
 
+### One resolver for the mesh
+
+*2026-10-03.* **The mesh's names live in one place: the module holding `mesh-resolver`**, a mesh-scoped
+seat of capacity one, placed on the node every tunnel converges on. It holds one wildcard per node —
+`<node>.internal` and everything under it — and listens on the private network only. Every node's
+`node-resolver-config` routes the mesh's suffix to it and leaves every other name with public
+resolvers; plain `resolv.conf` cannot route by domain, so the asking side is a stub that can
+(systemd-resolved, the tunnel's link carrying the suffix as its routing domain). The container runtime
+cannot use a loopback stub, so its `dns` names `mesh-resolver`, which forwards public names for
+containers — the one place a public name passes through the mesh
+([ADR 0194](../../02-DECISIONS/0194-the-mesh-has-one-resolver-and-every-node-asks-it-for-the-meshs-names.md)).
+
+**No node holds a copy.** The per-node resolver, its zones file and the mesh's region of `/etc/hosts`
+go: every resolution fault found on 2026-10-03 was a copy disagreeing with the truth — a hosts file
+read once at start, an operator's old line beside the mesh's, a node's resolver lent to a LAN. No
+member's resolver answers a LAN; a router pointing at one is moved first. *Checked by `resolvectl` on
+each node (the tunnel's link, `mesh-resolver`, the suffix as routing domain), by no node but the
+holder listening on port 53, and by the router's DHCP DNS option naming no node.*
+
+*What follows describes the per-node resolver this replaces — how it was built and why the roles were
+split. The split stands; the serving role's scope is what moved.*
+
 ### The resolver, built
 
 *2026-08-31.* **A service is reached at `<service>.<node>.internal`** — the first label is the
@@ -988,6 +1012,9 @@ The list is worth having in one place, because it is most of the argument:
 
 ## Open
 
+- **One resolver ([ADR 0194](../../02-DECISIONS/0194-the-mesh-has-one-resolver-and-every-node-asks-it-for-the-meshs-names.md)).** Not built: every node still runs
+  `node-dns-resolver`. The migration's four steps are in the record, in order.
+
 - ~~**What happens when the hub is down.**~~ **Resolved** by
   [ADR 0006](../../02-DECISIONS/0006-the-substrate-and-the-control-plane.md), together with `06`'s
   matching question — they were one question. Nothing takes over. WireGuard has no failover, the