fix(moshpit): decide the namespace by the ending, not by a DNS failure

[ralyodio]

Moshpit names never resolved on my connection, and the reason is not in the Moshpit code — it is the assumption underneath it.

The bug

Resolution inferred "clearnet has no answer for this name" from ERR_NAME_NOT_RESOLVED. That only holds on a resolver that reports failure honestly. Mine does not:

# via the system resolver              # via 1.1.1.1
california.oranges -> 69.46.46.24      california.oranges -> NXDOMAIN
foo.eggs           -> 69.46.46.24      test.eggs          -> NXDOMAIN
random9876.oranges -> 69.46.46.24

NXDOMAIN hijacking. Every nonexistent name answers, so ERR_NAME_NOT_RESOLVED never fires, so in the default mode (where that error is the only trigger) nothing ever ran and every Moshpit name landed on the hijacker's page. No amount of fixing the resolution policy helps while DNS is the signal.

The fix

Decide from the ending, which we hold locally — clearnet can only answer for an ending that exists on the real internet. Every hostname now falls into exactly one territory, decided without touching the network:

territory	example	behavior
moshpit	blue.eggs	resolved in both modes, clearnetResolves=false, no waiting on a DNS error
clearnet	google.com	default mode returns before any storage read or registry call; only opt-in moshpit mode looks up
reserved	*.onion, .local	dropped in both modes, never sent to the registry
none	a.b.c, 1.2.3.4	not a Moshpit-shaped hostname

This makes the code match what the options page has always claimed: "Moshpit names always resolve here — clearnet has never heard of those endings. This setting only decides what happens when both namespaces answer."

A leak this closes on the way

A v3 onion address is 56 alphanumeric characters plus .onion — exactly two alphanumeric labels, so parseRegistryName accepted it:

duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion
  -> {"label":"duckduckgogg42...","tld":"onion"}

In moshpit mode every Tor navigation therefore sent the onion address to the registry — and the pit's hosts deliberately bypass the SOCKS proxy, so that request left over clearnet carrying the address being visited. That is a deanonymization leak, not a wasted round-trip. Reserved endings are now dropped before the registry in either mode.

Also relevant to the "Moshpit is slowing down browsing" report

In the default mode an ordinary navigation to a real ending now costs one Set lookup — no chrome.storage read, no registry request. Previously every two-label hostname read storage, and in moshpit mode every one of them cost a registry round-trip (8s budget) before the tab settled.

Shape of the change

• tlds.js + tld-data.js — IANA's 1,438 endings plus the reserved set, with the reasoning for each reserved entry.
• moshpit-routing.js — the territory decision, lifted out of background.js so it is testable without standing up a service worker.
• background.js — two listeners, now thin wiring.
• scripts/update-tlds.mjs — regenerates the list from IANA. Deliberately a manual chore, not a build step: a release should not depend on data.iana.org being up.

The shared resolution policy (decideResolution and friends) is untouched, so all three copies still agree and moshpit-drift.test.js stays green.

Verification

• 25 new tests (tlds.test.js 14, moshpit-routing.test.js 11) covering the hijack case, the .onion leak, the no-registry-traffic guarantee, and totality.
• pnpm build && pnpm test — full workspace green; apps/desktop goes 8 → 10 test files, 68 extension tests pass including the untouched drift test.
• pnpm lint — exit 0.
• Release packaging verified: build-release.sh copies the extension wholesale then deletes *.test.js, so the three new runtime modules ship and the two test files do not.

🤖 Generated with Claude Code

[github-actions]

vu1nz Security Review

0 finding(s) in PR #?

No security issues found.