Skip to content

feat(pit): a DNS tab, so the namespace is reachable from a machine - #124

Merged
ralyodio merged 2 commits into
mainfrom
feat/pit-dns-tab
Jul 31, 2026
Merged

feat(pit): a DNS tab, so the namespace is reachable from a machine#124
ralyodio merged 2 commits into
mainfrom
feat/pit-dns-tab

Conversation

@ralyodio

Copy link
Copy Markdown
Contributor

The pit will sell you scrambled.eggs and then leave you with no way to open it. Resolvers now exist (moshcoder/moshcoding#77) that answer Moshpit names from this registry and forward everything else to the ordinary internet. This is the page that tells a person how to use one.

A tab, not a link in a paragraph. /pit is the namespace, /pit/dns is how you reach it — two halves of the same thing, and nobody finds the second one buried in prose.

The page

  • The addresses to put in your DNS settings, from MOSHPIT_DNS_RESOLVERS.
  • Set it — macOS, Windows, Linux, router, and DoH in the browser for a locked-down machine where DNS is not yours to change.
  • Check it workeddig +short anything.moshpit next to dig +short example.com, because "did I break the internet" is the first question.
  • What still breakshttps:// on a Moshpit name warns (no public CA will issue for a namespace outside the ICANN root), and clearnet lookups are forwarded to Google and Cloudflare.
  • Run your own — no dependencies, no database, reads this registry over ordinary HTTPS.

Addresses are config, not source

They are operational facts that change when a box moves, and a page that keeps telling people to use an address that moved is worse than one that says nothing.

Unset — which is the state today — the page says the resolvers are not published yet and explains how to run one. It never invents an address for a stranger to paste into their network settings, and entries that are not addresses are dropped rather than rendered, since that list exists to be copied into network settings.

MOSHPIT_DNS_RESOLVERS=dns1.pit.moshcode.sh=203.0.113.7,dns2.pit.moshcode.sh=203.0.113.8
MOSHPIT_DOH_URL=https://dns.pit.moshcode.sh/dns-query

Verified

  • Rendered both states against a local server: with addresses configured (both IPs, DoH endpoint, active tab on /pit/dns) and without (the "not published yet" copy, no invented address).
  • /pit still 200s with the tab strip and Namespace active.
  • 6 new tests; full suite 170 pass, 0 fail.

🤖 Generated with Claude Code

@github-actions

Copy link
Copy Markdown

vu1nz Security Review

0 finding(s) in PR #?

No security issues found.

ralyodio and others added 2 commits July 31, 2026 04:41
The pit could sell you `scrambled.eggs` and then leave you with no way to open
it. Resolvers now exist (moshcoder/moshcoding#77) that answer Moshpit names
from this registry and forward everything else to the ordinary internet — this
is the page that tells a person how to use one.

A tab rather than a link in a paragraph: `/pit` is the namespace and `/pit/dns`
is how you reach it, two halves of the same thing, and nobody finds the second
one buried in prose.

The addresses come from MOSHPIT_DNS_RESOLVERS rather than the source, because
they are operational facts that change when a box moves, and a page that keeps
telling people to use an address that moved is worse than one that says
nothing. Unset — which is today — it says the resolvers are not published yet
and explains how to run one. It never invents an address for a stranger to
paste into their network settings, and entries that are not addresses are
dropped rather than rendered.

Also states what does not work: HTTPS on a Moshpit name warns, because no
public CA will issue for a namespace outside the ICANN root, and clearnet
lookups are forwarded to Google and Cloudflare. Both are reasons to run your
own, which the page then tells them how to do.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`/pit?name=mosh.whatever` is where a resolver or the gateway sends someone
whose name did not resolve to a site. They have just demonstrated demand for a
name, so the page opens with what they can do about it rather than a 404.

Four honest answers, because what can be offered depends on who holds the
ending, and today only a TLD's owner may mint names under it:

  nobody holds `.whatever`  -> claim the ending, prefilled; the name and every
                               other one under it comes with it
  you hold it               -> one form, prefilled, registers `mosh.whatever`
  you already minted it     -> it is yours, it is in your list
  someone else holds it     -> say so. `registerName` refuses anyone but the
                               owner and there is no way for them to sell it
                               through the pit yet, so an offer button would be
                               an invitation into a flow that does not exist

The decision lives in lib/moshpit-landing.mjs with no database and no request,
so the wording is testable and cannot drift from the rule it describes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@ralyodio
ralyodio marked this pull request as ready for review July 31, 2026 04:45
@ralyodio
ralyodio merged commit ceb0360 into main Jul 31, 2026
3 checks passed
ralyodio added a commit to moshcoder/moshcoding that referenced this pull request Jul 31, 2026
…ge (#79)

Someone types `mosh.whatever`. Today the registry has no ending called
`.whatever`, so the resolver hands back clearnet's verdict — NXDOMAIN, a
browser error page, and a person who just demonstrated demand for a name walks
away. This turns that into the front door.

Two halves. The gateway now redirects any Moshpit Host it does not serve to
`app.moshcode.sh/pit?name=<host>`, where the pit offers them the ending the
name sits under (moshcoder/moshcode#124). A redirect rather than a proxy:
proxying would leave people signing in under a hostname no CA will vouch for,
with a session cookie on a domain the app does not own.

The other half is MOSHPIT_DNS_CATCHALL, off by default, which makes unclaimed
names resolve to the gateway at all. Without it the funnel only works for
endings someone already claimed, which is the wrong half of the audience.

The boundary is the entire feature. `asdkjh.com` is NXDOMAIN too, and answering
it would make this a typo-squatter for the whole internet — the behaviour ISPs
were rightly hated for. So the catch-all fires only when the TLD itself is
absent from the legacy root, checked by asking the upstreams for its SOA (one
cached query per ending, not per name) rather than by shipping an IANA list
that is stale the week after it is written. An unreachable upstream fails
closed: unknown means the root has it, because the alternative is handing the
internet to the catch-all during an outage.

Answers say what they are: `aa` is 0 since nobody holds the name, and TXT
reports `unclaimed=1`. Off by default — answering for names the registry never
granted is a product decision, not a default a resolver should assume.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@ralyodio
ralyodio deleted the feat/pit-dns-tab branch August 8, 2026 17:06
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