feat(dns): trust a name on the strength of its pin, and stop blaming the registry - #279
Draft
ralyodio wants to merge 1 commit into
Draft
feat(dns): trust a name on the strength of its pin, and stop blaming the registry#279ralyodio wants to merge 1 commit into
ralyodio wants to merge 1 commit into
Conversation
…the registry Two failures from the same first run, neither of which the machine could explain. 1. `dns enable` printed "no TLDs claimed yet — nothing to route" on a machine where the registry holds 5674 endings. The fetch had failed and the failure was swallowed to an empty array, so a network problem was reported as a fact about the registry — sending someone to claim an ending they already own. Same bug as the one fixed in `dns start`; this is the other half of it. The two cases now read differently, and the failure prints the curl that checks it. 2. The certificate error survived everything. moshpit-proxy verifies the registry pin and re-signs with a local root, but nothing routes to it: the resolver answers the origin, the proxy sits on loopback, and the two were never connected. So the root installed by #275 signs nothing, and `curl https://seo.rank` still meets the origin's self-signed certificate. `dns trust <name>` closes that without the proxy at all. A Moshpit name serves a self-signed leaf whose SAN names only itself, so trusting it vouches for that one name — a far smaller grant than a root, and why this path needs no name-constraints argument to be defensible. The pin check is what separates it from recklessness. Installing whatever answered the socket is trusting whoever reached the port first; installing it only when the registry already vouches for that exact key is registry-backed trust, which is a stronger claim than domain validation ever made. Every published pin is accepted, not just the first, because the registry lists the old one beside the new during a rotation precisely so a key can change without a flag day. A registry outage is reported as an outage, never as a rejected certificate: the answer to "the registry is down" is to wait, not to distrust a name. Verified against the live registry — the key seo.rank serves matches the pin the Pit publishes, and trusting that leaf takes curl from error 60 to 200. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ThreatCrush Security Scan88 finding(s) HIGH/CRITICAL: 50 | MEDIUM: 38
…and 38 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
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.
Two failures from one first run, neither of which the machine could explain.
1. "no TLDs claimed yet" was not true
The registry holds 5674 endings. The fetch had failed, and the failure was swallowed:
So a network problem was reported as a fact about the registry — which sends someone off to claim an ending they already own. This is the same bug fixed in
dns start, in the command next to it.The two cases now read differently, and the failure prints the one-liner that settles it:
2. The certificate error survived everything
moshpit-proxyverifies the registry pin and re-signs with a local root. But nothing routes to it:The resolver answers the origin, the proxy waits on loopback, and the two were never connected —
moshpit-dnshas no loopback mode at all. So the root installed by #275 signs nothing, andcurl https://seo.rankmeets the origin's self-signed certificate exactly as before. That was my error in #275: I assumed the proxy was in the path.dns trust <name>Closes it without the proxy. A Moshpit name serves a self-signed leaf whose SAN names only itself, so trusting it vouches for that one name — a far smaller grant than a root, and the reason this path needs no name-constraints argument to be defensible.
The pin check is what separates it from recklessness:
and when it does not match, nothing is written and nothing is refreshed:
Installing whatever answered the socket is the definition of trusting whoever reached the port first. Installing it only when the registry already vouches for that exact key is registry-backed trust — a stronger claim than domain validation ever made, since it proves registry ownership rather than momentary control of a socket.
Details that are deliberate:
ECONNREFUSEDcontains the wordREFUSED— the same confusion one layer down.)Verified against the live registry
23 new tests in
test/trust.test.mjs, generating real self-signed leaves with openssl. Suite green.