fix(dns): detect the proxy with a real name, not a synthesised one - #468
Merged
Conversation
The proxy probe is a TLS handshake with the name in SNI, and the pinned-TLS
proxy can only present a certificate for a name that exists — it fetches the
registry pin to mint one. Both `dns enable` and `dns service` probed with
`a.<first-ending>`, which is never a real name.
Measured against a proxy installed, trusted and listening on 127.0.0.1:443:
a.moshpit -> no certificate
a.2600 -> no certificate
alt.2600 -> issuer=CN=Moshpit Local CA
So a working proxy reported as absent, the unit was written without --proxy,
names answered their origin, and every https:// URL failed with a self-signed
certificate that nothing in any output explained. The bridge was healthy, the
routing correct, the proxy running, the root trusted — and the only wrong thing
was the name used to ask.
No registry endpoint lists names, so a real one cannot be discovered here.
`--proxy-probe <name>` supplies one, and the issuer check still runs against it:
naming a probe says which name to ask about, never that a proxy is there. A bare
flag is reported as the typo it is rather than falling back to the synthetic
name that cannot work.
The synthetic default is kept for the no-flag case: it is right on a machine
whose proxy serves every ending, and removing it would turn "detected nothing"
into "refused to look".
The not-found message now separates the two causes it was conflating — not
installed, versus installed and probed with a name it cannot serve — because
the remedy is completely different.
Suite: 2734 tests, 0 failures.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ThnQwoieWt8VR6N7gtgnhp
ThreatCrush Security Scan1 finding(s) in the 2 file(s) this pull request changes. HIGH/CRITICAL: 1
90 pre-existing finding(s) elsewhere in the repository — **HIGH/CRITICAL**: 7 | **MEDIUM**: 73 | **LOW**: 10Not introduced by this pull request. The full set is in the Security tab.
…and 70 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The proxy probe is a TLS handshake with the name in SNI, and the pinned-TLS proxy can only present a certificate for a name that exists — it fetches the registry pin to mint one. Both
dns enableanddns serviceprobed witha.<first-ending>, which is never a real name.Measured against a proxy installed, trusted and listening on
127.0.0.1:443:a.moshpita.2600alt.2600issuer=CN=Moshpit Local CASo a working proxy reported as absent, the unit was written without
--proxy, names answered their origin, and everyhttps://URL failed with a self-signed certificate that nothing in any output explained. Bridge healthy, routing correct, proxy running, root trusted — the only wrong thing was the name used to ask.The fix
No registry endpoint lists names, so a real one can't be discovered here.
--proxy-probe <name>supplies it, and the issuer check still runs against it: naming a probe says which name to ask about, never that a proxy is there. A bare flag is reported as the typo it is, rather than falling back to the synthetic name that cannot work.The synthetic default stays for the no-flag case — it's right on a machine whose proxy serves every ending, and removing it would turn "detected nothing" into "refused to look".
The not-found message now separates the two causes it was conflating (not installed, versus installed and probed with a name it can't serve) because the remedy is completely different.
Tests
Four on
proxyProbeFromArgs, extracted so the choice is testable rather than buried in the handler: named probe used verbatim, registry skipped when a name is given, bare flag rejected, synthetic fallback preserved.Suite: 2734 tests, 0 failures.
🤖 Generated with Claude Code
https://claude.ai/code/session_01ThnQwoieWt8VR6N7gtgnhp