v0.88.0 — a probe that parses

The proxy was found by asking about a name that cannot exist

dns enable tests for the pinned-TLS proxy by asking it for a certificate over TLS, and it named that test a.${tlds[0]} — the letter a, and whichever ending the registry returns first.

That held for as long as the first ending was a word. It is 00 now, so the probe asks about a.00, and https://a.00/ is rejected outright by the WHATWG URL parser: a final label of digits makes the whole host a candidate IPv4 literal, and a.00 is not a valid one.

The result was not a poor error message. Detection concluded there was no proxy on a machine that had, three lines earlier, installed one, started it, and confirmed it holding 127.0.0.1:443:

ok   proxy holds 127.0.0.1:443
--   no pinned-TLS proxy on this machine
--   https://a.00/ not verified yet — ERR_INVALID_URL

The bridge was then started without proxy mode, so every Moshpit name answered its origin directly and a stock client got a certificate no authority had signed — on a machine whose setup had otherwise completed perfectly, local root installed into the system trust store and all.

The probe stays synthetic. The proxy mints a certificate for any name inside the namespace, so the test does not have to name something anybody registered; it only has to parse. So an all-numeric ending is skipped when one is chosen.

Numeric endings remain sellable, and wanted — .420 and .2600 are names people ask for. Nothing here refuses them. They are unusable as a probe, which is a different thing, and is why this picks a different ending to test with rather than the registry turning them away.

--proxy-probe <name> overrides, for a machine where the choice has to be a particular real name. That flag has existed since v0.83.0; it was added for this exact failure, to one of the two commands that needed it.