A consumer's route name resolves to its oidc-client provider's node inside the mesh #227

Closed
opened 2026-09-30 18:39:21 +00:00 by mesh-admin · 1 comment
Contributor

Seen on ace after W9 grafana (2026-09-30, controller 990ef27, catalogue 1eb8fa36):

grafana.zurag.be       ace resolver: 10.10.0.1   (novox)   public DNS: 84.193.151.6 (ace)
supabase.zurag.be      ace resolver: 10.10.0.2   (ace)
baserow.zurag.be       ace resolver: 10.10.0.2   (ace)
f1-circuits.zurag.be   ace resolver: 10.10.0.2   (ace)
matrix.zurag.be        ace resolver: 84.193.151.6

grafana is the only ace module that binds oidc-client from novox's keycloak; keycloak receives the consumer's route name in the grant (oidc.json: name: grafana.zurag.be, from: novox). The mesh resolver appears to register that name against the provider's node, so from any mesh machine https://grafana.zurag.be lands on novox's route-proxy, which has no certificate for it: curl: (35) TLS connect error … tlsv1 alert internal error. Via public DNS (ace's traefik) the route answers 200. Expected: a route name resolves to the node whose route serves it; a grant carrying a consumer's name (redirect URI) should not add a resolver record. Side note: matrix (two route contributions) resolves to the public address rather than 10.10.0.2 like the single-contribution modules — maybe the same code path.

Seen on ace after W9 grafana (2026-09-30, controller 990ef27, catalogue 1eb8fa36): ``` grafana.zurag.be ace resolver: 10.10.0.1 (novox) public DNS: 84.193.151.6 (ace) supabase.zurag.be ace resolver: 10.10.0.2 (ace) baserow.zurag.be ace resolver: 10.10.0.2 (ace) f1-circuits.zurag.be ace resolver: 10.10.0.2 (ace) matrix.zurag.be ace resolver: 84.193.151.6 ``` grafana is the only ace module that binds `oidc-client` from novox's keycloak; keycloak receives the consumer's route name in the grant (`oidc.json`: `name: grafana.zurag.be`, `from: novox`). The mesh resolver appears to register that name against the provider's node, so from any mesh machine `https://grafana.zurag.be` lands on novox's route-proxy, which has no certificate for it: `curl: (35) TLS connect error … tlsv1 alert internal error`. Via public DNS (ace's traefik) the route answers 200. Expected: a route name resolves to the node whose route serves it; a grant carrying a consumer's name (redirect URI) should not add a resolver record. Side note: matrix (two route contributions) resolves to the public address rather than 10.10.0.2 like the single-contribution modules — maybe the same code path.
Author
Contributor

Recorded and resolved as hq issue 178 (04-ISSUES/178-a-routed-name-resolves-to-a-provider-merely-told-it/00-report.md), fixed by mesh-controller #181: every node's resolution is read first and a name is attributed to the terminus — the provider not itself published under a labelled name through another — in a fixed order, so the names region no longer flips and a module routed under several names has every one of them resolved. Rolling out now; the live check is two plans of the home server identical in the names region, with the dashboard's name at the home server's address.

hq's issues live in 04-ISSUES/ with status in their frontmatter, not in this tracker; closing here.

Recorded and resolved as hq issue 178 (`04-ISSUES/178-a-routed-name-resolves-to-a-provider-merely-told-it/00-report.md`), fixed by mesh-controller #181: every node's resolution is read first and a name is attributed to the terminus — the provider not itself published under a labelled name through another — in a fixed order, so the names region no longer flips and a module routed under several names has every one of them resolved. Rolling out now; the live check is two plans of the home server identical in the names region, with the dashboard's name at the home server's address. hq's issues live in `04-ISSUES/` with status in their frontmatter, not in this tracker; closing here.
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: novox/hq#227