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
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>
0 commit comments