Tools

The isitdns dig tool

run it right here; the full tool has every option

Yes. The dig tool at isitdns.net runs a real query from a Cloudflare edge location against the resolver you pick, over DoH, DoT or TCP, and renders the answer with the same annotations you would read in a terminal. Nothing to install, and every query prints its command-line equivalent.

This page is the reference manual for the dig tool at isitdns.net: what every control does and what every output line means. If you want guided examples instead of a manual, start with dig-examples.

The tool is a web dig. You pick a name, a record type, a resolver, and a transport; the query runs and the answer renders in annotated dig-style output. No install, no terminal. Every query also shows its command-line equivalent (dig, kdig, nslookup), so the tool doubles as a command builder for your own terminal.

Asks a resolver to name the node that answered.

$ dig @8.8.8.8 example.isitdns.net A +nsid

; <<>> DiG 9.20.11-0ubuntu0.2-Ubuntu <<>> @8.8.8.8 example.isitdns.net A +nsid

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status:

NOERRORThe server had no complaint about the question.

, id: 4595

;; flags:

qrThis message is the answer coming back, not the question going out.

rdYou asked this server to go and find the answer for you.

raThis server says it is willing to go and find answers for you.

adThis server says it checked the signatures, and they held up.

; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 512

; NSID: 67 70 64 6e 73 2d 61 74 6c ("gpdns-atl")

;; QUESTION SECTION:

;example.isitdns.net. IN

AYou asked for the IPv4 address this name points at.

;; ANSWER SECTION:

example.isitdns.net.

300How many seconds this answer can be reused before asking again. From a cache it is the time left, so it counts down.

IN A 192.0.2.1

;;

Query timeHow long this one lookup took, start to finish.

: 46 msec

;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

;; WHEN: Mon Sep 14 17:42:31 CDT 2026

;; MSG SIZE rcvd: 77

good: NOERROR and an NSID line in the pseudosection

bad: no NSID line, which means that resolver does not publish one

Where the query runs from#

The query does not run from your machine. It runs from a Cloudflare edge location, normally the one nearest you, and goes straight to the resolver you picked over DoH (RFC 8484), DoT (RFC 7858), or classic DNS over TCP (RFC 1035 §4.2.2).

That is the point, not a caveat. Your own dig rides your local resolver path: the OS stub, the router, whatever sits on port 53 between you and the resolver you named. Many home routers and corporate firewalls intercept port 53 and answer in the named resolver's place. The tool's path has none of that. So:

Run a query here.
Run the same query from your own terminal (the tool prints the exact command).
If the two answers differ, the difference is the finding: something on your local path is rewriting, filtering, or intercepting your DNS.

when-its-dns covers what to do with that finding.

Inputs#

Name to look up#

Free text, up to 100 characters. Accepted:

Any hostname whose labels follow RFC 1035 §2.3.1: letters, digits, hyphens, max 63 characters per label.
. alone, the root zone (useful with type NS to list the root servers).
A trailing dot is allowed and stripped.

Rejected, with an inline error under the field:

Non-ASCII input. Convert internationalized names to punycode first.
A bare IPv4 address. The field wants a name; an IP belongs in the Resolver dropdown (or, for reverse lookups, use the PTR type with the in-addr.arpa name, see reverse-dns).
Empty labels (consecutive dots) and labels over 63 characters.

Type#

24 record types, in three groups as the dropdown presents them:

Group	Types
Common	A, AAAA, CNAME, MX, NS, TXT, CAA, SOA, SRV, PTR, ANY
DNSSEC	DS, DNSKEY, RRSIG, NSEC, NSEC3, CDS, CDNSKEY
Service and security	HTTPS, SVCB, TLSA, SSHFP, NAPTR, DNAME

Each type has its own wiki page; the records overview indexes them. ANY has special modern behavior, covered in the ANY note below.

Resolver#

The dropdown has three special entries at the top, then the public resolvers grouped by what they are optimized for:

All public (compare): fans the same query out to every runnable public resolver in parallel (16 today) and renders one result block per resolver. This is the "which resolvers disagree" view.
Custom... (your own resolver IP): reveals an IP field. Covered in Custom resolver IPs.
Trace from root... (walks root, TLD, domain): an iterative walk, covered in Trace from root.

The runnable set is every public resolver in the registry that publishes a DoH endpoint. As of this page:

Resolver	Primary IP	Group in dropdown
Cloudflare	1.1.1.1	Mainstream
Google	8.8.8.8	Mainstream
Quad9 (unfiltered)	9.9.9.10	Mainstream
AdGuard (Non-filtering)	94.140.14.140	Mainstream
Quad9	9.9.9.9	Security / malware blocking
OpenDNS (Cisco Umbrella)	208.67.222.222	Security / malware blocking
CleanBrowsing	185.228.168.9	Security / malware blocking
Cloudflare for Families (Malware)	1.1.1.2	Security / malware blocking
DNS4EU (Protective)	86.54.11.1	Security / malware blocking
AdGuard DNS	94.140.14.14	Ad and tracker blocking
Control D	76.76.2.2	Ad and tracker blocking (the p2 profile)
AdGuard Family	94.140.14.15	Family-safe filtering
CleanBrowsing Family	185.228.168.168	Family-safe filtering
OpenDNS FamilyShield	208.67.222.123	Family-safe filtering
Cloudflare for Families (Family)	1.1.1.3	Family-safe filtering
Mullvad DNS (Base)	194.242.2.4	Privacy-focused

Resolvers the site lists but cannot query (no public DoH endpoint, e.g. NextDNS) appear grayed out so the directory stays complete without offering a query that can only fail. The default selection is Cloudflare.

Read the Control D row twice. Over DoH, which is the tool's default transport, the query goes to Control D's free ads-and-tracking profile, which is why the row sits in the ad-blocking group, on 76.76.2.2, Control D's p2 profile (malware and ads), which is also the DoH endpoint the board probes. 76.76.2.0 is the unfiltered p0 profile and is not on the board. Paste 76.76.2.2 into your own dig to reproduce the board's answer (vantage note: from inside a filtering network your path may answer first).

Transport#

Option	Port	What goes on the wire
DoH (default)	443	Wire-format DNS in an HTTPS POST, RFC 8484
DoT	853	Wire-format DNS over TLS, RFC 7858
Do53: TCP	53	Classic DNS framed in TCP, RFC 1035 §4.2.2
Do53: UDP	53	Listed but disabled. The tool's edge function cannot send UDP; see limitations

Two combinations warn before you run, because they fail at connect time from this vantage:

Cloudflare (1.1.1.x) over DoT or Do53. The tool runs inside a Cloudflare Worker, and Workers refuse raw TCP to other Cloudflare-fronted services. Use DoH for 1.1.1.1. In an all-resolver compare over DoT/Do53, the Cloudflare entries render as an explicit "skipped" card with this reason instead of a fake failure.
Do53 (TCP) over IPv6. The outbound path refuses raw TCP/53 to v6 destinations. DoT over IPv6 works.

Connect via (IP family)#

IPv4, IPv6, or Both. Only meaningful for DoT and Do53, where the tool opens a socket to an IP it chooses:

IPv4 / IPv6: connect to the resolver's published v4 or v6 address.
Both: run the query twice per resolver, once per family, and render the two results side by side. Resolvers that publish no v6 address skip the v6 run.

For DoH the row is disabled: the request goes to the resolver's hostname URL and the runtime picks the family itself.

Custom resolver IPs#

Selecting Custom... reveals an IP field. It accepts up to 6 IPv4 or IPv6 addresses, separated by spaces or commas; each IP becomes its own query and its own result block. That makes "ask each of this zone's authoritative servers the same question" a one-click job:

dig @coleman.ns.cloudflare.com example.isitdns.net A +norec

is the terminal equivalent of Custom + that server's IP + the +norec flag. When Custom and +norec are both active the form shows a small +norec -> RD=0 tag as a reminder that the query is now shaped for an authoritative server.

Over DoH the tool can only guess the endpoint https://<ip>/dns-query, and most servers do not serve DoH at their bare IP. When that guess fails the error says so and points you at Do53 (TCP) or DoT, which query the raw IP directly. Prefer those transports for custom IPs.

Trace from root#

Emulates dig +trace: an iterative walk that starts at the root nameservers and follows referrals down (root, TLD, zone) with recursion off at every hop, the way a resolver populates a cold cache. Each hop renders as its own block: the server asked, the zone it covers, the rcode and latency, the NS referral it returned, and the glue addresses. The final block is the authoritative answer, tagged with the aa server that gave it. No resolver or IP input is needed. Background: anatomy-of-a-query.

Flags#

Six toggle chips. Hovering any chip shows what it changes in the query. Five change the wire query; one changes only the display.

Chip	What it changes	Reference
`+dnssec`	Sets the DO bit in the EDNS0 OPT record: asks the resolver to send the DNSSEC records back with the answer. It does not switch validation on or off; a validating resolver validates either way, and returns `ad` either way. Off by default.	RFC 4035 §3.2.1, RFC 6891
`+cd`	Sets the CD (Checking Disabled) header bit: the resolver hands back data whose signatures failed instead of SERVFAIL. It takes effect whether or not `+dnssec` is on, because DO only controls whether the DNSSEC records come back, not whether validation happens. Proof, measured through this tool's own DoH path to Google: `dnssec-failed.org` A is SERVFAIL with CD off and NOERROR with CD on, DO off both times.	RFC 4035 §3.2.2
`+subnet`	Adds an EDNS Client Subnet option and reveals a CIDR field (`8.8.8.0/24`). Lets you ask "what would a user in this subnet get". Google honors ECS; Cloudflare ignores it by policy.	RFC 7871
`+norec`	Clears the RD (Recursion Desired) bit: answer only from what you already hold. The right shape for querying authoritatives; public recursives split on it, and the split is itself a teachable result (see failures). Measured 2026-09-04 across seven of them, `9.9.9.9` and Control D answered REFUSED while `1.1.1.1`, `8.8.8.8`, OpenDNS, AdGuard and CleanBrowsing answered from cache.	RFC 1035 §4.1.1
`+nsid`	Adds the NSID option: asks the answering server to identify which anycast instance handled the query.	RFC 5001
`+short`	Display only, nothing changes on the wire: show just the answer values, one per line. Unlike real `dig +short`, a failure rcode still renders (see failures).

Explanations are always on: the rendered output carries inline ; teaching comments and hover tooltips on every flag, rcode, TTL, and record type. There is no toggle to turn them off.

Reading the output#

Run this (the form equivalent: name example.isitdns.net, type A, resolver Google, +nsid on):

dig @8.8.8.8 example.isitdns.net A +nsid

The tool renders one result card per resolver queried:

Google   dns.google (auto)   history ↗                        52 ms

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

;; QUESTION SECTION:
;example.isitdns.net.		IN	A

;; ANSWER SECTION:
example.isitdns.net.	300	IN	A	192.0.2.1

;; Query time: 52 msec
;; SERVER: Google (dns.google (auto):443) via DoH
;; NSID: "gpdns-iad" (6770646E732D696164)
;; FLAGS REQUESTED: rd nsid

Line by line:

The card header. Resolver name, then the endpoint the tool actually connected to, then the round-trip time. For DoH the endpoint is the resolver's DoH hostname marked (auto), because the runtime picks which of its addresses to dial. For DoT and Do53 it is the exact IP the socket was opened to, including the v6 address when you chose IPv6. Monitored resolvers also get a history ↗ link into the site's uptime history for that resolver.

The HEADER line. Opcode, status (the RCODE), and the 16-bit transaction ID. The status token is color-coded, and the coloring is a fixed rule: NOERROR renders green. NXDOMAIN renders amber, because "this name does not exist" is a definitive answer, not a malfunction. Every other rcode renders red: SERVFAIL, REFUSED, FORMERR, NOTIMP, and the extended set. The decoder merges the extended-RCODE bits from the OPT record per RFC 6891 §6.1.3, so 12-bit codes such as BADVERS and BADCOOKIE display under their real names instead of a wrong 4-bit alias.

The flags line. Only the flags actually set in the response render, each with its own color and a hover tooltip: qr aa tc rd ra ad cd. A color-matched legend repeats under the results. The full story of each flag is on dig-flags; the two worth watching here are ad (the resolver validated DNSSEC for this answer, which it will tell you whether or not you sent +dnssec: measured 2026-09-04, a plain query for example.isitdns.net comes back ad from 1.1.1.1, 8.8.8.8 and 9.9.9.9 alike) and aa (the answering server owns the zone, so a cached answer never carries it).

The counts on this line are the counts from the wire header. One deliberate mismatch: ADDITIONAL: 1 with no ADDITIONAL section below it means the one additional record was the OPT pseudo-record, EDNS plumbing per RFC 6891. The tool does not render OPT as a record; its useful payload surfaces as the NSID line, the EDE line, and the extended rcode instead.

QUESTION SECTION. Your query echoed back, so you can see what the server actually answered for.

ANSWER SECTION. The records, in dig's five columns: name, TTL, class, type, data. Values are semantically colored (addresses, hostnames, MX targets) and every field has a hover explainer. When the answer is empty the placeholder tells you which kind of empty it is:

Placeholder	Meaning
`; (no records: the name does not exist)`	NXDOMAIN
`; (no records of this type: NODATA)`	NOERROR, name exists, no records of the asked type
`; (no answer here: the server returned a referral, see AUTHORITY below)`	NOERROR, non-authoritative NS-only authority: a delegation referral
`; (no records returned: SERVFAIL)` (or other rcode)	any failure rcode

AUTHORITY SECTION. Renders whenever the response carries authority records. Three normal reasons: the SOA of the covering zone on negative answers (NXDOMAIN and NODATA, the negative-caching proof from RFC 2308); NS records when an authoritative server refers you down the tree; NSEC/NSEC3 denial proofs from signed zones when +dnssec is on.

ADDITIONAL SECTION. Renders whenever the response carries additional records besides OPT, typically glue: the addresses of the nameservers named in AUTHORITY.

Query time. Milliseconds for the full exchange, measured at the edge function: connect (or HTTPS request), query, response. The same number appears in the card header.

SERVER line. The resolver's name, the endpoint dialed, the port as a hoverable pill (443, 853, or 53), and the transport label (DoH, DoT, Do53 (TCP)).

NSID line. Only present when you sent +nsid and the server answered with the option (RFC 5001). Printable identifiers render as text with the raw hex in parentheses: ;; NSID: "gpdns-iad" (6770646E732D696164) is Google's way of saying an IAD (Washington Dulles) instance answered. Non-printable identifiers render as hex only. Many operators do not return one.

EDE line. Present whenever the response carried an Extended DNS Error (RFC 8914), rendered as ;; EDE <code> <name>: <text> directly under the flags. It is the server's own stated reason for the rcode, never the tool's guess, and several can arrive at once. extended-dns-errors is the code table and the reading guide.

FLAGS REQUESTED. What the tool actually put on the wire for this query: rd, do, cd, ecs, nsid, or (none). When +norec is on, rd is honestly absent from this line.

The ANY note (RFC 8482)#

When an ANY query returns NOERROR with an empty answer, the tool appends an explainer banner: minimal ANY responses are deliberate, per RFC 8482, because full ANY answers were abused for DDoS amplification. Operators differ in how they minimize, and the tool shows whatever came back:

Google hands back the RFC 8482 signal record, HINFO "RFC8482" "". It is not Google's invention: ask example.com's own authoritative servers and they return the same HINFO, signed by the zone (checked 2026-09-04 against hera and elliott.ns.cloudflare.com).
Cloudflare answers ANY with rcode NOTIMP, which renders red with its explainer.

Both captured live from the tool. dig-examples has the guided version.

Reading failures#

Real output from the tool, every time in the same order: who we asked, what came back, verdict last.

NXDOMAIN#

We asked Cloudflare (1.1.1.1) for not-a-real-website.example A. Came back:

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

;; ANSWER SECTION:
; (no records: the name does not exist)

;; AUTHORITY SECTION:
.	86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. ...

NXDOMAIN renders amber, not red. Verdict: the name does not exist, and the SOA in AUTHORITY is the proof, naming the zone that said no (here the root, because .example is a reserved TLD) and, in its last field, how long resolvers may cache the no (RFC 2308).

SERVFAIL#

We asked Quad9 (9.9.9.9) for dnssec-failed.org A with +dnssec on. This zone is deliberately signed wrong. Came back:

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

;; ANSWER SECTION:
; (no records returned: SERVFAIL)

SERVFAIL renders red. Verdict: the resolver tried and gave up. With this zone the cause is DNSSEC validation failure; in general SERVFAIL also covers upstream timeouts and broken zones. Two follow-ups the tool makes easy: re-run with +cd (a validating resolver will then hand back the data it just refused, proving validation was the blocker), and re-run against a non-validating resolver. Read the ;; EDE line first when one is present: the resolver has already named the cause, and extended-dns-errors decodes it. dnssec-troubleshooting takes it from there.

REFUSED#

We asked Quad9 (9.9.9.9) for example.isitdns.net A with +norec on. Came back:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 6914
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
; (no records returned: REFUSED)
;; FLAGS REQUESTED: (none)

REFUSED renders red. Note rd is absent from both the response flags and FLAGS REQUESTED: the tool really did clear it. Verdict: the server declined to answer, by policy. A recursive asked not to recurse has nothing to offer unless the answer is cached; an authoritative answers REFUSED when you ask it about a zone it does not host. Match the query shape to the server: +norec for authoritatives, recursion for recursives.

NODATA#

We asked Cloudflare (1.1.1.1) for example.isitdns.net MX. The name exists (it has A and AAAA records) but has no MX. Came back:

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

;; ANSWER SECTION:
; (no records of this type: NODATA)

;; AUTHORITY SECTION:
isitdns.net.	1800	IN	SOA	coleman.ns.cloudflare.com. dns.cloudflare.com. ...

NOERROR renders green even though the answer is empty, because nothing failed. Verdict: the name exists, records of this type do not. NODATA is the answer that tells you to check which type you asked for; NXDOMAIN would have told you to check the name.

Timeout and unreachable#

We asked a custom IP, 203.0.113.1 (a reserved test address, nothing listens there), for example.isitdns.net A over Do53 (TCP). Came back an error card in place of dig output:

Custom (203.0.113.1)   203.0.113.1                        1 ms
proxy request failed, cannot connect to the specified address

Verdict: no DNS conversation happened at all, so there is no rcode to show, and the tool does not invent one. Connection failures and timeouts (the tool waits 8 seconds on DoH, 3.5 seconds on DoT and Do53 before giving up) both land here, with the transport error verbatim. The card still names the exact IP it tried, which matters in a v6 run: the error tells you which family broke.

Share these results (under the output) and the share button copy a URL that recreates the query. The recipient's form populates and the query auto-runs. The URL is the #dig fragment plus these parameters:

Parameter	Meaning	Example
`name`	the queried name	`name=example.isitdns.net`
`qtype`	record type	`qtype=MX`
`resolver`	resolver id, or `all`, `custom`, `trace`	`resolver=quad9`
`customIps`	comma-separated IPs when resolver is `custom`	`customIps=9.9.9.9,8.8.8.8`
`transport`	`doh`, `dot`, or `tcp53`	`transport=dot`
`ipv`	`v4`, `v6`, or `both`	`ipv=both`
`ecs`	ECS CIDR (implies the `+subnet` chip)	`ecs=8.8.8.0/24`
`dnssec`, `cd`, `norec`, `nsid`, `short`	flag chips, `1` = on	`dnssec=1`
`preset`	a learning-example chip by slug (replaces all of the above)	`preset=nxdomain`
`autorun`	`0` = populate the form but do not run	`autorun=0`

A worked link: isitdns.net/#dig?name=example.isitdns.net&qtype=A&resolver=google&nsid=1 reproduces the NOERROR example above.

"Share these results" copies the reproduce commands, the rendered output with the teaching annotations stripped, and the link, ready to paste into a ticket.

Copy as a command#

The command preview above the Run button always shows the terminal equivalent of the current form, and three buttons copy the variants:

Copy dig: the dig line with the transport flags (+https, +tls, +tcp) stripped, so it runs on any dig over plain Do53. The on-screen preview keeps the transport flag, honestly showing that dig needs BIND 9.18+ for +https.
Copy kdig: the same query for kdig (from knot-dnsutils). +tls for DoT arrived in Knot DNS 2.3.0 and +https for DoH in 3.0.0, and +https needs a build linked against libnghttp2 (kdig manual). Shown whenever the transport is DoH or DoT.
Copy nslookup: the closest nslookup line. nslookup is Do53-only and supports only the type and server, so that is all the line carries; see nslookup-and-dig for why.

The round trip closes: the form state example.isitdns.net, A, Google, +nsid copies as

dig @8.8.8.8 example.isitdns.net A +nsid

and running that from a clean vantage returns the same 192.0.2.1 the tool showed. If it does not, re-read Where the query runs from: the difference is your local path, and now you have both outputs to compare.

What the tool cannot do#

From the code:

It is not your vantage. Every query originates at a Cloudflare edge location. The tool can prove what a clean path sees; it cannot see what your machine sees.
No UDP. The Worker has no UDP sockets, so classic dig's default transport is the one thing this tool cannot use. The UDP option is listed disabled until that changes. Consequence: the tc (truncated) flag is rare here, since DoH, DoT, and TCP all carry full-size answers.
Cloudflare resolvers over DoT/Do53 are skipped. The Worker cannot open raw TCP to other Cloudflare-fronted services, so 1.1.1.1, 1.1.1.2, and 1.1.1.3 are DoH-only here.
Do53 (TCP) over IPv6 is refused by the outbound path. DoT over IPv6 works.
DoH cannot pin the IP family. The runtime dials the resolver's hostname and picks v4 or v6 itself; the family toggle is disabled for DoH instead of pretending.
Custom IPs over DoH are a guess (https://<ip>/dns-query). Use Do53 (TCP) or DoT for custom targets.
One query, no retry. Timeouts are 8 s (DoH) and 3.5 s (DoT/Do53), then the error renders. There is no UDP-then-TCP fallback dance, because nothing starts on UDP.
Custom fan-out caps at 6 IPs per run.
What the site records: a run counter, and a log line per query (name, type, resolver, transport, flags, any ECS value or custom IPs, plus the coarse country and edge location the request came through). No cookies, no visitor identifier, nothing that links queries to a person.