You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(pit): serve a name at an IPv6 address, and say how on the page (#190)
* feat(pit): serve a name at an IPv6 address, and say how on the page
A name could be pointed at an IPv6 address and then not work, in two
different ways, neither of which said so.
The bridge only answered A. An AAAA query got an empty answer and the
target went into `ipv4()`, which returned null, which is NXDOMAIN — so a
name pointed at a v6 address did not resolve at all. It now answers both
families, and an A query for a v6-only name comes back NOERROR with no
answers rather than NXDOMAIN: browsers ask for both, and NXDOMAIN on the
A half is entitled to take the AAAA answer down with it.
The gateway built `http://2606:4700::1111:80/`, which is not a URL — the
address's own colons are indistinguishable from the port separator, so
fetch threw and every v6 name 504'd as "the origin could not be reached".
`checkTarget` now returns the origin with the host bracketed.
Targets are validated when they are written rather than only when they
are fetched, and IPv4 literals are refused: an A record on a small host
is usually leased or NATed, and a name pointed at one goes stale without
telling anyone. Hostnames still work. Storing an unroutable address now
fails at the form instead of minting a name that 502s for every visitor.
Also adds the instructions to the page the field is on, with the Caddy
and nginx blocks — including the `http://` Caddy needs, since no public
CA will issue for an ending that is not in the DNS root.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(cli): moshcode template — starting stacks for Moshpit-hosted services
Hosting at a Moshpit ending is four files and one non-obvious fact: the
machine serving the name never resolves it, and every visitor's machine
must. People get that wrong the same way every time, so this ships a
template that already has it right rather than a paragraph they read
after the site failed to come up.
moshcode template list
moshcode template install bun-caddy-sqlite [--into dir] [--force]
moshcode template install <git-url|owner/repo|url.tar.gz>
Two bundled to start: bun-caddy-sqlite (Bun + Caddy + SQLite, local file
or Turso behind the same libsql client) and caddy-static.
Nothing in a template is executed on install, including the bundled ones
— the point of `install <url>` is that the URL is a stranger's, and a
template that could run on install would be remote code execution
wearing a scaffold's clothes. Files are copied; what to run is the
reader's call. Archive members are checked against path escapes before
tar unpacks rather than after, since a unit written to a path of the
archive's choosing is a root shell on the next boot. An install that
would clobber an existing file writes nothing at all.
The bundled units include one for the DNS bridge. `dns enable` sets up a
resolved drop-in (a file, survives a reboot) and a bridge process (does
not), so after a restart the routing points at a port with nothing behind
it and names stop resolving with no obvious cause. That unit is the
missing half.
Verified live: bun install, the service up on loopback, SQLite counting
visits per name across requests, and the gateway's x-moshpit-name header
taking precedence over Host.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments