Readme: isitdns

the answer

Run 2026-09-29, thewizard.

One word. The rows say who.

$ curl -sL isitdns.net

is it DNS?

  no. DNS is fine.

  17/17 up   median 27 ms from thehermit   updated 2026-09-29 11:45 UTC

  Cloudflare   ok       26 ms
  Google       ok       18 ms
  Quad9        ok       17 ms
  AdGuard DNS  ok       27 ms

  read from 4 isitdns probes (thehermit, theoracle, theranger, thewizard), not your network
  check your own path: https://isitdns.net/diagnose

11:45Z. Cut for length.

the answer in dns

Written into the zone. TXT is the sentence.

$ dig +short help.isitdns.net TXT

"is it DNS? no. DNS is fine. 17/17 resolvers answering, median 25 ms from thehermit, as of 2026-09-29T11:43:11Z" "ask: isit why top10 top100 ksk <resolver>, all .isitdns.net TXT; A ladder 127.0.0.2 no, .3 mostly, .4 maybe, .5 no data; 127.0.0.1 is never ours; tokens, one string in isit and here: state (ok, degraded, failing, stale), bad, measured, seats, asof; " "concatenate the strings of a line, no separator" "receipt: https://isitdns.net; probe: ours not yours, your path: https://isitdns.net/diagnose" "state=ok bad=0 measured=17 seats=4 asof=2026-09-29T11:43:11Z"

11:45Z. First string for a person, last string for a script.

A is the number.

$ dig +short help.isitdns.net A

127.0.0.2

11:45Z. .2 no, .3 mostly, .4 maybe, .5 no data. 127.0.0.1 is never ours: a captive portal or a hosts file answers that by accident.

Why is one line.

$ dig +short why.isitdns.net TXT

"all 17 measured resolvers answering, as of 2026-09-29T11:43:11Z"

11:45Z. On a bad day it names the resolver.

one resolver, four legs

17 public resolvers, each with its own name.

$ dig +short cloudflare.isitdns.net TXT

"cloudflare ok 25 ms, dnssec validating, as of 2026-09-29T11:42:37Z " "v4 doh 9ms ok " "v4 dot 47ms ok " "v6 doh 4ms ok " "v6 dot 47ms ok"

11:45Z. IPv4 and IPv6, DoH and DoT, each its own reading. dnssec validating: the ad flag came back on a signed name.

the root key roll

The root DNSSEC key rolls on 2026-10-11: 20326 is the old key, 38696 the new one (IANA root anchors, ICANN). Four names from RFC 8509 section 2, under probe.isitdns.net, a signed zone of ours.

"Is this the Key Tag of a key that the validating DNS resolver is currently trusting as a trust anchor?"

$ dig @1.1.1.1 root-key-sentinel-is-ta-38696.probe.isitdns.net A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27022
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

20:46Z. Cut for length.

$ dig @1.1.1.1 root-key-sentinel-is-ta-20326.probe.isitdns.net A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36342
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

20:46Z. Cut for length.

"Is this the Key Tag of a key that the validating DNS resolver is *not* currently trusting as a trust anchor?"

$ dig @1.1.1.1 root-key-sentinel-not-ta-38696.probe.isitdns.net A

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52932
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

20:46Z. Cut for length.

$ dig @1.1.1.1 root-key-sentinel-not-ta-20326.probe.isitdns.net A

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1915
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

20:46Z. Cut for length.

Resolver	is-ta 38696	is-ta 20326	not-ta 38696	not-ta 20326
old key only	SERVFAIL	answers	answers	SERVFAIL
mid-roll (trusts both)	answers	answers	SERVFAIL	SERVFAIL
rolled (old dropped)	answers	SERVFAIL	SERVFAIL	answers
not validating, or no sentinel support	answers	answers	answers	answers

1.1.1.1 above: mid-roll.

monitored domains

The domains we monitor, from a list we keep. The first ten get a line.

$ dig +short top10.isitdns.net TXT

"top 10, 2026-09-28: google.com ok, youtube.com ok, facebook.com ok, instagram.com ok, x.com ok, twitter.com ok, whatsapp.com ok, wikipedia.org ok, amazon.com ok, yahoo.com ok"

11:45Z. The newest snapshot.

the protocol

A fixed set of names under a zone, as TXT (words and tokens) and as A (a loopback ladder). Any zone can carry it: draft-shelton-isitdns-00, an Internet-Draft for independent submission.

$ dig +short isit.isitdns.net TXT

"state=ok bad=0 measured=17 seats=4 asof=2026-09-29T11:43:11Z" "no"

11:45Z. state= is ok, degraded, failing or stale; bad= counts the resolvers failing from every probe that read them (degraded with bad=0: failing from some probes, answering from others); measured= counts the resolvers with a verdict; seats= counts the probes the readings came from. RFC 5782 is why the ladder starts at 127.0.0.2 and never uses 127.0.0.1. A hosts file or a captive portal answers 127.0.0.1 by accident.

where we measure from

Every probe is a machine we run.

Probe	Where	What it does
`theoracle`	Phoenix	Measures the resolvers.
`thehermit`	not published	Measures the resolvers.
`cf-edge`	Cloudflare's edge	Where the site runs. The KSK line is read from here.
`thewizard`, `theranger`	Amsterdam and Singapore	Measure the resolvers. Live since 7 September 2026.

A probe that goes quiet stales its own column.

$ dig +short canary.probe.isitdns.net A

192.0.2.111

11:45Z. From your machine this must print 192.0.2.111. Anything else, or nothing, is something between you and us answering in our place.

the dig tool, from a terminal

Runs from the isitdns edge, and prints the line to run the same question from yours.

$ curl -s -H 'Accept: text/plain' https://isitdns.net/dig/example.com

  isitdns · dig · example.com A
  ;; asked 2026-09-29T11:45:53.524Z over DoH (dnssec on) from the isitdns edge, not your network

  ;; @cloudflare (cloudflare-dns.com (auto)) over DoH · 139 ms · 179 bytes · NOERROR · flags: qr rd ra ad
  ;; asked 2026-09-29T11:45:53.524Z from the Cloudflare edge (AMS), remote address unavailable from this vantage
  ;; ANSWER (3)
  example.com.                     294  IN  A      172.66.147.243
  example.com.                     294  IN  A      104.20.23.154
  example.com.                     294  IN  RRSIG  A 13 2 300 20260930124547 20260928104547 34505 example.com. 7VQDxPCR8wxweioHQr3ycADEXb+CLUbkH8zT41DSPgioIqzDC1laOJxW3oKM6ynMzEcVU+m5Bm8kM+0ZyCqzvA==  ; key tag 34505, inside its window, expires 24 h after this read (the signature itself is not checked here)
  ;; EDE: none received

  ;; the same question from your own machine: dig +https @one.one.one.one example.com A +dnssec

  browser: https://isitdns.net/#dig?name=example.com&qtype=A&resolver=cloudflare

11:45Z.

the domain audit, from a terminal

11 readings, each with its value.

$ curl -s https://isitdns.net/check/example.com

  isitdns · domain audit · example.com

  source: 1.1.1.1 DoH (auth Cloudflare-fronted) · recursion: theoracle (Phoenix) probe

  1. Parent/child NS consistency      ok    Parent and child agree on all 2 nameservers. None of the 2 nameserver names is an alias or `NXDOMAIN` (names outside the zone answered by Cloudflare 1.1.1.1 over DoH). (1.1.1.1 DoH)
  2. Open recursion check             ok    Answered `REFUSED` with no records to a recursive query for `dns.google`. Measured from our theoracle (Phoenix) probe.
  3. DNSSEC presence + validation     ok    A `DS` and a `DNSKEY` are published and Cloudflare 1.1.1.1 set the `AD` bit (1.1.1.1 DoH)
  7. CAA (cert issuance lock)         warn  No `CAA` records at `example.com` or at any ancestor up to `com` (read through Cloudflare 1.1.1.1, not at the zone's nameserver), so any CA may issue for it (RFC 8659 section 3) (1.1.1.1 DoH)
  11. UDP truncation and TCP fallback  ok    108.162.192.162 answered the apex `DNSKEY` set over UDP with no `TC`, within 512 bytes with no EDNS and within 1232 with EDNS, and over `TCP` with the answer. Measured from our theoracle (Phoenix) probe, off Cloudflare's network.

  8 ok · 1 warn · 0 fail · 2 skipped · read 2026-09-29 11:45 UTC

11:45Z. Cut for length.

your privacy

No accounts, no ads, no profiles, no PII.

Page views are counted, cookieless.

if it is dns

The rest lives in the wiki, built around real records you can dig yourself.

a note from the author

1. It's always DNS. Until it isn't.

2. Free, because who wants another login these days.

3. Make the tools as easy as possible.

My first "big IT" job after the helpdesk made me learn the fundamentals: the OSI model, peer reviews, pre and post change checks. As in, actually test that it worked before somebody blames your change. They will blame your change.

When it's your turn in the hot seat (you picked IT, the hot seat comes with it), you'll be the one sharing your screen with a terminal open while the VPs and the CFO throw around their new favorite three letter word: DNS.

I built this so you have backup in that moment. So you can say "no, it's not DNS, here's why it's the network."

/fin

Thanks for visiting.

comments? admin@isitdns.net

Neal