How aaaa.bot measures

What every aaaa.bot answer is based on — so you can judge it, cite it, or disagree with it. Method version 1.

DNS

• Records are looked up over DNS-over-HTTPS: Cloudflare first, Google if Cloudflare fails.
• We ask for A and AAAA for the name and for its www, MX for mail, and NS for the zone (walking up from the name, skipping answers that arrive through a CNAME, which belong to someone else's zone).
• Answers are cached for their own TTL, never more than five minutes. A failed lookup is reported as "couldn't check" — never as "no IPv6".

Does it answer over IPv6?

• From one server on Fly.io, we open a TCP connection to each of up to four AAAA addresses, on port 443 and then port 80, with a three-second timeout. That's all: no TLS handshake, no HTTP request. "Answers" means the port accepted a connection.
• Only public (global unicast) addresses are contacted. Private, link-local, documentation and translation addresses are reported, never probed.
• If some addresses answer and others don't, the ones that didn't are retried once before we call them unresponsive.
• Before ever saying an address is broken, the server re-tests its own IPv6 connection (to Cloudflare's and Google's public DNS) — and that test must start after the failed attempts. If our own IPv6 is down, the answer is "couldn't test".

The grade

• A — the website (and www, if it exists) answers over IPv6, every mail server has an AAAA record, and at least one nameserver does.
• B — the website works over IPv6 with one gap; C — with two or more.
• D — no IPv6 address for the website. F — an IPv6 address is published but nothing answers on it.
• ? — something couldn't be checked. We'd rather say "?" than guess.
• Mail and nameserver checks look for AAAA records only; we don't connect to them. A domain with no MX records receives mail at its own address, so that address is what we check.

Does HTTPS work over IPv6? (not graded yet)

• Once the website's IPv6 address answers, we open a TLS connection to it, using the site's name, and check the certificate: trusted chain and covers the name.
• Then one HEAD request for / (a GET if HEAD isn't allowed), reading only the response headers, and up to five redirects. Each redirect target must have its own public IPv6 address — a redirect to an IPv4-only name is reported as a problem, because that's where IPv6 visitors end up.
• A wrong certificate or a redirect off IPv6 is a problem. Timeouts, server errors (5xx), loops and unusual ports are reported as "couldn't tell", because they aren't necessarily about IPv6.

A second opinion

On request, we ask Globalping's network of volunteer-run probes to load the site over HTTPS on IPv6 from up to six places around the world. Those results are theirs, not ours: each reflects that probe's own network, and a probe without working IPv6 shows up as a failed test, not as a problem with the site.

What this doesn't tell you

• Whether the whole page loads over IPv6 — we fetch only the first response, not images, scripts or third-party resources, which may come from IPv4-only hosts.
• Whether it works from everywhere — our own checks come from one place. The second opinion helps, but a handful of probes isn't the whole internet.

Evidence

Every domain check is saved with a permanent link (/r/…) and a plain-text record you can copy. Saved measurements are kept for 180 days. The top 1,000 sites are re-checked weekly and every result is kept, which is what the changes feed is made from.