Skip to content

fix(tunnel): detect cloudflared zone-mismatch routing and fail loudly#473

Open
bussyjd wants to merge 1 commit into
mainfrom
fix/tunnel-detect-zone-mismatch
Open

fix(tunnel): detect cloudflared zone-mismatch routing and fail loudly#473
bussyjd wants to merge 1 commit into
mainfrom
fix/tunnel-detect-zone-mismatch

Conversation

@bussyjd
Copy link
Copy Markdown
Collaborator

@bussyjd bussyjd commented May 12, 2026

Summary

  • obol tunnel login now parses cloudflared's tunnel route dns output and fails loudly if the routed hostname does not match the requested one (case-insensitive). Catches the silent zone-fallback failure mode where ~/.cloudflared/cert.pem is scoped to a Cloudflare account that does not own the zone for the requested hostname — cloudflared appends its default zone (e.g. inference.v1337.orginference.v1337.org.example.com) and exits 0.
  • Helper verifyRoutedHostname is a pure function on the cloudflared output string; no Cloudflare API calls (locally-managed mode has no API token). Unknown log shapes are treated as "no signal" so an upstream log-format change cannot break the happy path.
  • New table-driven TestVerifyRoutedHostname covers both success log shapes, both mismatch shapes, empty output, mixed-case tolerance, and unknown-shape pass-through.

Test plan

  • go test ./internal/tunnel -count=1 -run 'TestVerifyRoutedHostname|TestRouteDNSArgs' (7 subtests pass)
  • go build ./...
  • Manual: re-run obol tunnel login --hostname inference.v1337.org on a host whose ~/.cloudflared/cert.pem is scoped to a different zone — expect a clear error pointing at cert.pem, no helm/manifest apply
  • Manual: happy-path obol tunnel login against a correctly-scoped cert.pem still succeeds end-to-end

`obol tunnel login --hostname X.example.com` shells out to
`cloudflared tunnel route dns <tunnel> X.example.com`. If
~/.cloudflared/cert.pem is scoped to a Cloudflare account that does
not own the zone for the requested hostname, cloudflared silently
falls back to the cert account's default zone and routes DNS to
`X.example.com.<default-zone>` instead — but exits 0. Obol only
checked the exit code, so it reported success and the rest of the
helm/manifest apply ran against a hostname that will never resolve
publicly.

Add `verifyRoutedHostname`, a pure parser of cloudflared's combined
stdout/stderr matching the two known success log shapes:

  Added CNAME <hostname> which will route to this tunnel ...
  <hostname> is already configured to route to your tunnel ...

If the extracted hostname does not match the requested one
(case-insensitive, trimmed), `Login` returns an actionable error
pointing the user at their cert.pem. Unknown log shapes are treated
as "no signal" so an upstream log-format change cannot break the
happy path.

Hit today on spark2 asking for `inference.v1337.org` against a
cert.pem scoped to the `humanresearch.ai` account; cloudflared
quietly routed `inference.v1337.org.humanresearch.ai` and obol
reported success, costing ~30 min debugging the wrong layer.
@bussyjd bussyjd force-pushed the fix/tunnel-detect-zone-mismatch branch from e788f34 to 1b0388d Compare May 12, 2026 09:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant