The gateway rebinding barrier judges Host against the bind, so a wildcard-bind install stops answering to its DNS name

[philcunliffe]

Deferred from the triage of PR #1271 (head ab56f4e83ea7481e59067f5bb728b4c8d59e8c92), review round 2 residual finding 2. Severity: medium.

Where

hypaware-core/plugins-workspace/ai-gateway/src/proxy.js:411, the rebinding barrier added by PR #1271.

Observed behavior

LLP 0233 #loopback-peers-only records a non-loopback listen as an operator-configurable, supported exposure (reverse-proxying to registered upstreams), and scoped the CONNECT refusal to the peer, not the bind, to keep such an install working. The new barrier judges Host against the bound address, and a wildcard bind earns no routable exemption (boundAddress is 0.0.0.0, never the arrival address). So after #1271 a client on another machine reaching a listen = "0.0.0.0" install by its DNS name (Host: gateway.corp:18521) gets 421, while the interface literal (Host: 192.168.1.10:18521) still passes. The install stops answering to its DNS name.

Why deferral is safe

This is the same trade PR #1236 already shipped on the OTLP and OpenCode listeners, and issue #1239 settled it explicitly ("no config key widens the accepted set"). Widening the accepted set here would be a design change against a settled decision, not a fix. Non-loopback binds are a rare, deliberate operator configuration; the workaround (address the gateway by the routable interface literal, not by a name) works today and is documented in the README section this PR added ("On a wildcard bind a client on another machine has the same constraint as a remote exporter"). Default installs (127.0.0.1) are unaffected.

Acceptance condition

Either a decision (a new LLP extending 0233, or a recorded resolution on this issue) affirms that DNS-name addressing of a wildcard-bound gateway stays refused, or a mechanism ships under which a request arriving on a wildcard bind may be accepted under a name that resolves to the arrival address, covered by a test showing Host: <dns-name>:<port> accepted on a 0.0.0.0 bind while Host: attacker.example on a loopback bind is still refused.

[philcunliffe]

Stuck: needs an affirmation neutral cannot give itself

What neutral was doing. This issue was next in the fix queue. It was read
before dispatch and not dispatched, because its acceptance condition cannot be
met by writing code.

Why it cannot proceed. The acceptance offers two branches, and neutral can
take neither on its own authority:

1. Affirm that DNS-name addressing of a wildcard-bound gateway stays refused,
   recorded either as a new LLP extending 0233 or as a resolution on this issue.
2. Widen the accepted set so a request arriving on a wildcard bind may be
   accepted under a name resolving to the arrival address.

Branch 2 is a design change against a settled decision: the issue says so, and
that checks out. LLP 0233 is Status: Accepted, and #1239, which settled this
exact trade ("no config key widens the accepted set"), is CLOSED as completed.
Neutral does not reopen settled decisions by patch.

Branch 1 is an affirmation, not an implementation. Neutral can observe that the
current behavior matches the settled decision, but a record saying "this is
intended" is a statement of intent, and intent is the maintainer's to declare.
Writing it as neutral would be manufacturing authority it does not have.

Deliberately not escalated to a request LLP. Two of those were already
minted this session for genuinely open questions (LLP 0381 in #1368, LLP 0382 in
#1374). This one is different: nothing here is undecided. #1239 and LLP 0233
already settled it, and the only gap is that the consequence for a wildcard bind
was never written down. A third RFC would restate a settled decision rather than
ask anything, so a one-line answer here is the proportionate move.

What it needs from you: one of two answers.

• "Affirmed, it stays refused." Then this closes as working-as-designed. The
  workaround already ships and is documented in the README section PR Fix #1238: The ai-gateway proxy is a third loopback listener serving the control route and catch-all routing with no Host check #1271
  added: address the gateway by the routable interface literal, not by a name.
  Optionally the consequence gets a sentence in LLP 0233, which is a matter of
  record-keeping rather than design.
• "Widen it." Then this becomes a design request against LLP 0233 and Host check refuses a machine-hostname-addressed local OTLP exporter on Debian/Ubuntu (127.0.1.1) with no escape hatch #1239,
  and neutral will mint the RFC on the next tick if you say so. Note the shape
  the acceptance already specifies for the test: Host: <dns-name>:<port>
  accepted on a 0.0.0.0 bind, while Host: attacker.example on a loopback
  bind is still refused.

Scope of the impact, for the decision. Default installs (127.0.0.1) are
unaffected. This bites only a deliberate non-loopback operator configuration,
where after PR #1271 a client on another machine reaching a listen = "0.0.0.0"
install by DNS name gets 421, while the interface literal still passes, because
boundAddress is 0.0.0.0 and never the arrival address
(hypaware-core/plugins-workspace/ai-gateway/src/proxy.js:411).

How to unstick. Reply with a comment on this issue; neutral monitors this
thread and will re-engage with your guidance on its next tick.