Ask DNS if it is DNS

This page answers one question: how do I get the isitdns verdict without a browser? You dig for it. The monitor writes its answer into the isitdns.net zone every 3 minutes, so any resolver on earth can hand it back to you as a TXT record.

$ dig @1.1.1.1 help.isitdns.net TXT

The verdict and the asof stamp in that record move every few minutes. The shape of the answer is what is stable.

The one query#

dig +short help.isitdns.net TXT

"is it DNS? no. DNS is fine. 17/17 resolvers answering, median 68 ms, as of 2026-09-12T14:12:00Z" "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; seat: ours not yours, your path: https://isitdns.net/diagnose" "state=ok bad=0 measured=17 seats=1 asof=2026-09-12T14:12:00Z"

One line, five quoted strings, because dig prints every string of one record on one line. Split them for reading:

dig +short help.isitdns.net TXT | awk '{gsub(/" "/, "\"\n\""); print}'

Five lines, four parts. The verdict the home page shows, word for word. The menu, which runs past 255 bytes and so arrives as the two strings in the middle. The receipt, where the evidence lives. The tokens, for a reader that is not a person.

The same board, in a terminal, over HTTPS instead of DNS: curl -sL isitdns.net prints the verdict, four resolvers and the median, and points at help.isitdns.net and the curl paths (/check/<domain>, /<domain>, /top100).

The other names#

dig +short why.isitdns.net TXT
dig +short quad9.isitdns.net TXT
dig +short ksk.isitdns.net TXT

The tokens, for a script#

isit and help each carry one string of key=value tokens beside the English. Same round, same numbers:

dig +short isit.isitdns.net TXT

"state=ok bad=0 measured=17 seats=1 asof=2026-09-12T14:12:00Z" "no"

Read asof every time you read state. The zone only changes when the writer runs, so a writer that has stopped leaves state=ok sitting there, correct at the moment it was written and wrong now. state=stale means the probe stopped reporting; it is not what a stopped writer produces, because a stopped writer produces nothing at all. A script that greps state=ok and nothing else prints "fine" over a dead surface forever.

dig +short isit.isitdns.net TXT | python3 -c '
import calendar, re, sys, time
t = dict(re.findall(r"(\w+)=([^\s\"]+)", sys.stdin.read()))
if "state" not in t or "asof" not in t: sys.exit("not fine: no state token in the answer")
age = int(time.time() - calendar.timegm(time.strptime(t["asof"], "%Y-%m-%dT%H:%M:%SZ")))
ok = t["state"] == "ok" and -180 < age < 600
print("fine, %ds old" % age if ok else "not fine: state=%s, %ds old" % (t["state"], age))'

600 seconds is the same bar the monitor holds itself to: three missed 3-minute rounds. Older than that and the answer is a record, not a reading. A stamp more than 180 seconds in the FUTURE fails too, for the same reason the monitor's own tripwire refuses one: a clock that far out means the stamp is not measuring what it claims to.

One seat took this reading. Nothing here is corroborated by a second network, and seats=1 is where that is said. On a board with no reading at all it is seats=0, because nothing measured it. The other seats isitdns runs fill the cross-vantage matrix and never the word.

The version record#

dig +short _isitdns.isitdns.net TXT

"v=isit1 surface=1 round=180 spec=https://isitdns.net/wiki/tools/ask-dns"

v=isit1 is the format of this record. surface= is the version of everything else on this page, and it goes up whenever a record's grammar, the ladder or the meaning of the stamp changes, so a parser can tell a format change from an outage without reading prose. round=180 is the measurement cadence in seconds. spec= is this page.

It is written by hand and not by the monitor, which is deliberate: the writer that updates the verdict every 3 minutes is refused every name beginning with an underscore, so a fault in it cannot rewrite the version of the surface it is serving. Its TTL is an hour, because it is not a reading and does not go stale on the probe's clock.

The A record ladder#

help and isit also answer an A query, so a plain dig help.isitdns.net with no type says the word too. The answer is a loopback address, the DNSxL convention from RFC 5782 section 2.1 (a borrowed convention: RFC 5782 governs blocklists and allowlists, and this surface is neither), which sets 127.0.0.2 as the conventional value and points at section 2.3 for a list that codes several meanings into several addresses, as this one does: nothing you could connect to, only a code.

The ladder starts at 127.0.0.2, and 127.0.0.1 is never one of ours. Section 2.1 makes .2 the conventional first value and section 5 forbids 127.0.0.1 as an entry, but the practical reason is closer to home: 127.0.0.1 is what a captive portal, a hosts file or an RPZ hands back by accident. If that meant "DNS is fine", the one answer you get when something is intercepting your queries would be the answer saying nothing is. Get 127.0.0.1 for one of these names and it did not come from here.

dig +short isit.isitdns.net A

Reading the stamp#

Four lines end in as of <time>Z: the verdict line, why, ksk and every resolver status line. A resolver that has per-leg readings carries them as extra strings after its status line, so the record ends in a leg and the stamp sits in the middle. The token string carries the same value as asof=. top10 and top100 carry the day of their sweep instead, because a daily board is dated by its day and not by a clock. The menu and the receipt carry nothing, since neither is a reading, and the bare word in isit carries nothing either, which is why a script should read isit's token string and not its word. The stamp is the newest probe sample behind the verdict, in UTC, not the moment the record was written. When there is no sample at all, the verdict says no data and the stamp is the time the answer was built. Each resolver is sampled every 3 minutes and the writer runs every 3 minutes, so a stamp older than about 10 minutes means the probe or the writer has stopped; the stamp alone does not say which. Either way the answer is old and should not be trusted as current.

The record's TTL is 60 seconds, so ask twice a minute apart and the second answer is a fresh one: if the stamp has not moved by then, nothing new has been written.

A TXT record is a set of character-strings (RFC 1035 section 3.3.14), each at most 255 octets of data: section 3.3 defines a <character-string> as "a single length octet followed by that number of characters", up to 256 including the length octet. A line longer than that is split into several strings, which is why dig +short prints more than one quoted piece for one record.

Concatenate the strings of a line. Add nothing between them. That is the rule RFC 7208 section 3.3 sets for SPF, and since 12 September 2026 it is the rule here too: a line is split at a space and the space stays inside the string in front of it, so the pieces join back byte for byte with no separator. Join them with a space instead and you get a double space at each split, never two words run together. The split point is still always a word boundary, which is ours and not RFC 1035's, so a reader who joins nothing at all still sees whole words in order.

What this is not#

It is not a probe of your path. The answer describes what the isitdns monitor saw from one vantage: it asks each of the 17 resolvers for one pinned canary name over DoT, every 3 minutes, and a resolver has to come back bad twice in a row before that counts as an incident rather than a flap. The same box also runs a DoH-first transport ladder over four rotating canary names every minute, as the prime vantage. That round never writes the board's numbers, and it cannot cancel a strike either: since 4 September 2026 the strike veto refuses a second opinion that shares the first one's uplink, and prime leaves through the same uplink as the board seat. What it does is fill the cross-vantage matrix and keep the heartbeat honest (functions/_prober.ts, functions/_db.ts). It says nothing about what your resolver did with your query. The part that answers "what did we see of you" is a different tool and is not on this surface.

See also#

• dig-tool runs the same queries from the browser
• dig-flags explains +short and the rest
• when-its-dns is what to do when the word is not no
• txt is the record type doing the work here