jschoubben
04c9500b5b
Issue 110's cause was not the filter: the runtime had never been told, and the resolver dropped a query arriving on a bridge. ADR 0148 step 3 landed once it did (109, 151 resolved). ADR 0151 composes a route's internal name under the serving node and drops the suffixed alias (139, 157 resolved). Design 08 amended; a fact in 0148 corrected.
64 lines
3.5 KiB
Markdown
64 lines
3.5 KiB
Markdown
---
|
|
status: resolved
|
|
opened: 2026-09-28
|
|
located-in: [mesh-controller internal/catalogue/declaration.go (composeName took the consumer's own name as the internal domain)]
|
|
fixed-by: mesh-controller PR 163 — the internal name composes under the node whose proxy serves the route (ADR 0151, 2026-09-30)
|
|
amended-design: 03-DESIGN/01-to-be/08-connectivity.md
|
|
---
|
|
|
|
# 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>.internal` with 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 `route` still 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.
|
|
|
|
## Answered (2026-09-30)
|
|
|
|
[ADR 0151](../../02-DECISIONS/0151-a-routes-internal-name-is-composed-under-the-node-that-serves-it.md):
|
|
the internal name is composed under the node that serves the route — the machine the request arrives
|
|
at — because `<x>.<node>.internal` means *goes to that node* and nothing else. The public name stays
|
|
the consumer node's, which is where the operator put it. The first question is answered that way; the
|
|
second, a per-node route holder, is a decision about seats and is left where it is; the third is
|
|
unchanged, since the proxy that terminates the name is given it and certifies it.
|
|
|
|
mesh-controller PR 163 carries it. On this mesh every route is served beside its module, so no name
|
|
changed; the controller's tests hold the case where it would.
|