How isitdns measures
Where the readings come from, the eleven checks behind a domain check, and the points behind the monitored domains board.
Asks 1.1.1.1 for the canary, the one answer every probe expects.
dig -4 @1.1.1.1 canary.probe.isitdns.net AGO NOERROR, one A record, 192.0.2.111
NO GO any other address, NXDOMAIN or SERVFAIL
Asked from a lab host whose IPv4 port 53 is not intercepted (a query to 192.0.2.1 from it timed out), 2026-10-07 00:53Z. The id, the Query time, the WHEN line and the TTL move on every run. 192.0.2.111 is in the documentation block of RFC 5737; the two queries to run from your own machine are on test your own path.
Where we measure from#
| Probe | Where | What it does |
|---|---|---|
theoracle | Phoenix | Measures the resolvers. |
thewizard, theranger | Amsterdam and Singapore | Measure the resolvers. Live since 7 September 2026. |
| the fourth probe, named on /readme | not published | Measures the resolvers. |
cf-edge | Cloudflare's edge | Where the site runs. The KSK line is read from here. |
The four named probes are machines we run; cf-edge is Cloudflare's network. A probe that goes quiet stales its own column.
How we measure#
| Thing | Reading |
|---|---|
| board | DoT, latency, ad flag, every 3 minutes |
| domain check | Do53, DoH, delegation, DNSSEC chain, on demand |
| verdict | names the failed rung |
| table | one row per resolver, one column per probe |
| stale | "no data." |
| every answer | read time |
| freshness | the limits, with the code's numbers, are on /readme |
Incidents and strikes#
An incident is one continuous run of something we watch being degraded or down. A strike is one logged incident. We count incidents, not bad seconds, so a long outage is one strike, not thousands.
The domain check#
Checking a domain runs eleven checks and tells you what each one found. There is no number out of 100 and no letter.
2026-09-11: 19 domains, 8 checks, 5 checks ok on all 19. No score.
11 rows: ok / warn / fail / skipped, reason, name asked. The last three were added on 2026-09-14: what the parent ships in its referral, whether the digest the parent publishes still matches a key the zone has live, and whether a server that truncates a UDP answer will serve it over TCP.
| check | what it asks |
|---|---|
ns-consistency | The nameservers the parent delegates to and the ones the zone publishes are the same set, and no nameserver name is an alias (RFC 2181 section 10.3) or NXDOMAIN. |
no-open-recurse | The zone's nameserver does not answer a recursive question for a name it does not serve. |
dnssec | A DS at the parent and a DNSKEY at the child, and the chain validates at a validating resolver. |
ttl-sanity | The apex A TTL and the SOA minimum. |
spf | An SPF record exists and ends in a qualifier that means something. |
dmarc | A _dmarc policy exists and is not p=none. |
caa | A CAA record names the certificate authorities allowed to issue. |
wildcard | Whether a wildcard answers for names nobody defined. |
glue | Each nameserver named inside the zone it serves has its address in the parent's referral, and that address is one the zone serves (RFC 2181 section 5.4.1). |
ds-matches-dnskey | The DS the parent publishes matches a DNSKEY live at the apex (RFC 4034 section 5.1.4). |
udp-truncation | Whether the server truncates the apex DNSKEY answer over UDP, and whether TCP returns it. |
Skipped is not failed. A check we could not run says so and is counted separately. Reverse zones (in-addr.arpa, ip6.arpa) do not send mail or hold certificates, so the three mail and certificate checks do not run there at all: eight rows instead of eleven.
Zone or name. A delegation, a DNSSEC chain, a nameserver's recursion policy, a zone's glue, its chain of trust and the size of its apex answers all belong to a ZONE. Asking about a hostname evaluates those six against the zone it sits in and the other five against the name itself, so the answer names the zone and marks the rows that belong to it. A registrable domain, which is most questions, gets neither because there is nothing to distinguish.
Points#
The monitored domains board has two orders. Rank is the order the board was stored in that day. Best is points: one integer per domain, 0 to 100, counted from what the zone publishes. Source: one reading a day at Cloudflare's recursive, from the Cloudflare edge. One vantage, not the authoritative servers.
| points | the question |
|---|---|
30 | signed The parent publishes a DS record, so the delegation is signed. |
15 | ipv6 The apex publishes AAAA. |
12 | ns-count The zone publishes two or more nameservers. |
10 | caa A CAA record at the apex limits which certificate authorities may issue. |
10 | mail The apex says what it does about mail: an MX, or an RFC 7505 null MX. |
10 | ttl The apex TTL reading does not exceed 86400s, and reaches 60s. |
8 | ns-parents Those nameservers sit under more than one registrable parent domain. |
5 | apex-direct No CNAME record is published at the apex itself. |
The weights sum to 100. No curve and no average: the number is the points earned, added up.
The TTL question is one-sided, because the reading is. We read the apex TTL through a caching resolver, which counts it down, so what we hold is a floor. Over 86400s is a proven miss: a floor above the band cannot come from a zone below it. Under 60s proves nothing, because a zone publishing 60s reads under 60 on every sample that is not a fresh fill, so that case is unknown and scores 0 rather than being counted against the zone. 60s to 86400s earns the 10.
Ties break by the stored rank, the lower rank higher: from 2026-09-24 that is the domain's line in a list we keep, and before it an outside daily ranking. Nothing else breaks a tie.
Three outcomes per question: earned, missed, unknown. Missed is measured and absent. Unknown is no answer, or a reading that cannot settle it. Both score 0, so every row carries a mark for it, and the expander on the board names the questions and their points. An unknown is not dropped from the total: one denominator per row.
No facts row, no rank. No number, not a zero, and the row sits at the end of the best order.
Us. isitdns.net is measured by the same path and the same formula, pinned above the board. It is not on the list and it is in none of the board's counts. It has no stored rank, so its position reads as the rows above it plus one, with the number of rows it ties with.
Not: a grade, a security rating, an operator ranking. It says nothing about networks: we read names and records, so nameservers under several parent domains earn those 8 points even when one company runs all of them. The parent is found with a short list of registry suffixes and not the full public suffix list, so nameservers under a two-part suffix we do not list can read as one parent and cost those 8 points. A flattened or ALIAS apex is not docked, because it answers A and AAAA at the apex; only a CNAME record at the apex itself loses those points. A ttl miss can still hide: a zone at two days whose readings all land inside the band earns the points.
Board data: CC BY 4.0.