2.5 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |
|---|---|---|---|---|---|
| open | 2026-09-28 |
|
139 — An internal route name resolves to the consumer's node, not the one that serves it
What was observed
A module that requires a route is given two names: a public one composed under the serving node's
domain, and an internal one composed under the consumer's own machine — <label>.<node>.internal.
The two are published differently:
- The public name is written into every machine's hosts file at the address of the node whose proxy answers it. The mesh computes that deliberately, so any container resolving a routed name reaches the proxy.
- The internal name is resolved by the machine's own resolver, which answers every name under
<node>.internalwith that node's address — the consumer's, because the name was composed from it.
Where the proxy runs beside the consumer these are the same machine, which is every case on this mesh today, and both names work. Measured on 2026-09-28: the internal name of a service on the control node answers with a certificate from the mesh's internal authority, and the public name with one from the public authority.
Where the proxy is on another machine they disagree. The internal name sends the client to a machine that runs no proxy and has nothing listening on the port, while the public name sends it to the one that does.
Why it matters beyond this instance
It is latent exactly where the mesh is heading. route is provided mesh-wide precisely so a
module can be routed by a proxy on another machine. The first module assigned that way gets an
internal name that does not work, and the public one that does — with no error anywhere, because both
names resolve.
A per-machine name is what an operator will reach for. <service>.<machine>.internal reads like a
promise that the service on that machine is reachable there, and the wildcard makes every such name
resolve whether or not anything answers.
Open questions
- Should the internal name be composed under the serving node, like the public one, or should it stay the consumer's and be published at the serving node's address like the public name is?
- Is a per-node route holder the real answer — a proxy on every machine that serves its own names —
and if so, is
routestill one mesh-wide provision or a node-scoped seat with a mesh-wide fallback? - What certifies the name in either case? The certificate is obtained by whoever terminates TLS, and that is the question above in another form.