feat(dns): --trust-all, so every name works without a command per name - #281
Merged
Conversation
`dns trust <name>` works and does not scale. Someone browsing Moshpit
meets a certificate error on every site they have not personally thought
about, which is indistinguishable from the namespace being broken.
`dns start --trust-all` trusts a name as it resolves: fetch the
certificate it serves, check the key against the pin the registry
published for that name, install it only on a match. Nothing is trusted
on sight — a name with no published pin gets nothing, silently and
forever — so this is registry-backed trust rather than trust-on-first-use.
Three ways the automation could go wrong, none about cryptography:
- blocking a DNS answer on certificate work. consider() queues and
returns; the drain runs detached from the query handler.
- asking once per query rather than once per name. A browser sends A
and AAAA together and retries, so "on resolve" is a firehose: ten
lookups of two names is two certificate fetches.
- retrying a name that will never succeed. A refusal is final for that
name until restart, or every lookup writes a log line and fails.
Only a name that actually resolved to one of ours is considered: a
forwarded clearnet name is not ours to trust, and NXDOMAIN has no origin
to fetch from. Without root it says so once, rather than failing per name
forever in the query log.
A registry outage is not narrated per name — if the registry is down
every name fails, and saying so each time turns the query log into the
outage. Only refusals and successes are reported.
Fixed while testing: idle() awaited a boolean rather than the in-flight
drain, so it reported a queue as settled while it was still being worked.
A flag can say someone else is draining; it cannot be awaited.
Stacked on #279, which added the per-name command this automates.
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. |
ralyodio
marked this pull request as ready for review
August 4, 2026 00:59
ralyodio
added a commit
that referenced
this pull request
Aug 4, 2026
…the registry (#279) * feat(dns): trust a name on the strength of its pin, and stop blaming 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> * feat(dns): --trust-all, so every name works without a command per name (#281) `dns trust <name>` works and does not scale. Someone browsing Moshpit meets a certificate error on every site they have not personally thought about, which is indistinguishable from the namespace being broken. `dns start --trust-all` trusts a name as it resolves: fetch the certificate it serves, check the key against the pin the registry published for that name, install it only on a match. Nothing is trusted on sight — a name with no published pin gets nothing, silently and forever — so this is registry-backed trust rather than trust-on-first-use. Three ways the automation could go wrong, none about cryptography: - blocking a DNS answer on certificate work. consider() queues and returns; the drain runs detached from the query handler. - asking once per query rather than once per name. A browser sends A and AAAA together and retries, so "on resolve" is a firehose: ten lookups of two names is two certificate fetches. - retrying a name that will never succeed. A refusal is final for that name until restart, or every lookup writes a log line and fails. Only a name that actually resolved to one of ours is considered: a forwarded clearnet name is not ours to trust, and NXDOMAIN has no origin to fetch from. Without root it says so once, rather than failing per name forever in the query log. A registry outage is not narrated per name — if the registry is down every name fails, and saying so each time turns the query log into the outage. Only refusals and successes are reported. Fixed while testing: idle() awaited a boolean rather than the in-flight drain, so it reported a queue as settled while it was still being worked. A flag can say someone else is draining; it cannot be awaited. Stacked on #279, which added the per-name command this automates. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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.
Stacked on #279 — review that first; this branch targets it, not main.
dns trust <name>works and does not scale. Someone browsing Moshpit meets a certificate error on every site they have not personally thought about, which is indistinguishable from the namespace being broken.Nothing is trusted on sight. A name is trusted only when the key it serves is one the registry already published for it, so this is registry-backed trust rather than trust-on-first-use. A name with no published pin gets nothing, silently and forever.
The three ways this could go wrong, none about cryptography
Blocking a DNS answer on certificate work.
consider()queues and returns; the drain runs detached from a UDP handler that owes a client a reply.Asking once per query rather than once per name. A browser sends A and AAAA together and retries, so "on resolve" is a firehose. Ten lookups of two names is two certificate fetches, and there is a test pinning that.
Retrying a name that will never succeed. A refusal is final for that name until restart. Otherwise every lookup of a mismatched name writes a log line and fails, forever.
Deliberate
Found while testing
idle()awaited a boolean rather than the in-flight drain, so it reported a queue as settled while it was still being worked. A flag can say someone else is draining; it cannot be awaited. Fixed, and the test that caught it is the last one in the file.9 new tests. Full suite green.