Check where one bound domain points and whether this machine is reachable from the internet

Where the name points, as this cloud sees it from where a visitor sits.

Split in two on purpose. addresses carries only globally routable answers; a private answer is counted and never rendered, because the web role's resolver inside compose is Docker's embedded DNS and printing what it said would describe this deployment's own network in a console panel. resolved therefore means "the lookup answered something", whether or not any of it is renderable.

addresses is also capped, so a name behind a long round-robin shows a sample of its answer rather than the whole of it. The verdict below is computed from the whole answer and never from this sample.

Where this machine dialled out from, as the relay saw it.

unavailable covers both "no connection to have observed" and "the address we saw is not one the internet routes to" — a machine behind the same NAT as the relay, or, in the dev stack, a fake daemon on the compose network. The two are one state because the console's answer is the same: we cannot compare it against DNS, so we do not pretend to.

Rendered live and stored nowhere (D-NC10). It is personal data.

Whether the internet can open a connection to this machine at all.

not_probed is not a failure: it is what an unavailable observed address forces, and it is the state the dev stack always shows.

The ACME preconditions, each from the source that actually knows it.

requested and cert_state come from the node's own row. acme_enabled comes from GET /api/capabilities — see :data:CAPABILITIES_PATH for why the row cannot answer it — and is None when that read could not be made or could not be read, which is a fault on one precondition and never a refusal of the whole check. http_reachable is the HTTP-01 precondition, and None when nothing was probed.