Live dig examples

Twelve real queries, each with a run-live link on the live dig tool; six of them are preset chips there. Each section below is the link, the command, the real answer, and what to read in it.

terminal: dig-along

Quick jump#

DNSSEC validated#

Run live: isitdns.net/#dig?preset=dnssec-validated

$ dig @1.1.1.1 cloudflare.com A +dnssec

The ad flag means the resolver walked the chain: RRSIG on the answer, DNSKEY that signed it, DS at the parent, hashes match (RFC 4035 §3.2.3). AD is hop-by-hop, not end-to-end: a stub behind a stripping proxy or captive portal never sees it even on a properly signed zone (RFC 6840), and an RRSIG in the answer shows signing, not validation (RFC 4035 §3.2.2).

See also: DNSSEC · DNSSEC troubleshooting

NXDOMAIN#

Run live: isitdns.net/#dig?preset=nxdomain

dig @1.1.1.1 not-a-real-website.example A

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=not-a-real-website.example&type=A'

{
  "Status": 3,
  "AD": true,
  "Question": [{"name": "not-a-real-website.example", "type": 1}],
  "Authority": [{"name": "", "type": 6, "TTL": 86400,
    "data": "a.root-servers.net. nstld.verisign-grs.com. 2026090200 1800 900 604800 86400"}]
}

"Status": 3 is NXDOMAIN: this name does not exist anywhere in the namespace. The Authority section carries the root's own SOA, because .example has no delegation at all (RFC 2606 reserves it for exactly this kind of test). How long resolvers cache that "no" is the lower of the SOA's minimum field and the SOA record's own TTL (RFC 2308 section 5).

See also: DNS fundamentals

ECS: US vs Asia-Pacific#

Run live: isitdns.net/#dig?name=www.adobe.com&qtype=A&resolver=google&ecs=4.2.2.0/24, and the Asia-Pacific hint

dig @8.8.8.8 www.adobe.com A +subnet=4.2.2.0/24
dig @8.8.8.8 www.adobe.com A +subnet=210.53.0.0/16

EDNS Client Subnet (RFC 7871) lets a resolver tell an authoritative "the real client is in this subnet," so a geo-aware CDN can route to an edge near the user rather than the resolver. +subnet= spoofs that hint from your own machine. Read the OPT pseudosection's CLIENT-SUBNET line: it prints sent-prefix/scope-prefix. A scope of 0 means the answer covers every client address (RFC 7871 §7.2.1) and both queries land on the same edge; a nonzero scope means the hint was honored, and the two answers may differ (RFC 7871 §6 defines SCOPE PREFIX-LENGTH).

Cloudflare's 1.1.1.1 sends no ECS at all: "It does not send the EDNS Client Subnet (ECS) header" (1.1.1.1 FAQ). Google's 8.8.8.8 does, truncated to /24 for IPv4 (Google Public DNS FAQ), which is why the example asks 8.8.8.8: 1.1.1.1 would not forward the hint even if you sent it.

See also: RFC 7871

DNSSEC: valid vs forced#

Run live: isitdns.net/#dig?name=dnssec-failed.org&qtype=A&resolver=cloudflare&dnssec=1 (expect SERVFAIL), and with &cd=1 (expect NOERROR)

dig @1.1.1.1 dnssec-failed.org A +dnssec
dig @1.1.1.1 dnssec-failed.org A +dnssec +cd

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=dnssec-failed.org&type=A'

{
  "Status": 2,
  "AD": false,
  "Question": [{"name": "dnssec-failed.org", "type": 1}],
  "Comment": ["EDE(9): DNSKEY Missing no SEP matching the DS found for dnssec-failed.org."]
}

dnssec-failed.org is a public fixture zone with intentionally broken signatures. Without +cd a validating resolver fetches the RRSIG and DNSKEY, hashes the DNSKEY, compares it to the parent's DS, finds no match, and returns SERVFAIL rather than serve unverifiable data (RFC 4035 §5.5). The Extended DNS Error names why: code 9, DNSKEY Missing (RFC 8914 §4.10). +cd (Checking Disabled) sets the header bit that disables the resolver's validation (RFC 4035 §3.2.2), so the second query returns the same broken answer as NOERROR.

If +dnssec alone fails but +dnssec +cd succeeds, DNSSEC validation is failing (RFC 4035 §3.2.2). If both fail, the resolver itself isn't returning data, usually an upstream connectivity problem.

See also: DNSSEC troubleshooting · DNSViz

PTR and reverse DNS#

Run live: isitdns.net/#dig?name=2.1.1.1.in-addr.arpa&qtype=PTR&resolver=cloudflare

dig @1.1.1.1 2.1.1.1.in-addr.arpa PTR

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=2.1.1.1.in-addr.arpa&type=PTR'

{
  "Status": 0,
  "Question": [{"name": "2.1.1.1.in-addr.arpa", "type": 12}],
  "Answer": [{"name": "2.1.1.1.in-addr.arpa", "type": 12, "TTL": 176,
              "data": "security.cloudflare-dns.com."}]
}

PTR answers "what name lives at this IP." DNS reads right-to-left, IPv4 reads left-to-right, so the lookup reverses the octets and appends .in-addr.arpa: 1.1.1.2 becomes 2.1.1.1.in-addr.arpa (RFC 1035 §3.5). IPv6 does the same with nibbles under .ip6.arpa (RFC 3596).

A public IP's PTR is owned by whoever controls that address block, not by whoever runs the service on it: your own laptop's PTR is your ISP's naming scheme, not yours. Mail is the practical case that bites: a sending IP whose PTR does not match its HELO name is a common reason inbound mail gets rejected.

See also: Reverse DNS · MX

Root nameservers#

Run live: isitdns.net/#dig?preset=root-nameservers

dig @1.1.1.1 . NS

The answer is NOERROR with 13 NS records, a.root-servers.net through m.root-servers.net: the entry points every recursive resolution starts from (RFC 1034). Each name is anycast across many physical sites operated by 12 organizations, so your packet lands on whichever instance is topologically closest (root-servers.org publishes live counts and maps); id.server CHAOS TXT reveals which one answered (RFC 4892). A resolver that wants to skip the public roots entirely can serve the full root zone locally instead (RFC 8806).

See also: NS · DNS fundamentals

DoH vs DoT#

Run live: isitdns.net/#dig?preset=doh-vs-dot

dig @9.9.9.9 +https iana.org A
kdig @9.9.9.9 +tls iana.org A

Both carry RFC 1035 wire format; only the transport wrapper differs.

macOS system dig (9.10) has neither flag; BIND 9.18+ adds them, or install kdig (apt install knot-dnsutils / brew install knot). ODoH (RFC 9230) adds a proxy so the resolver can't link the client IP to the query.

See also: DoT, DoH, DoQ · the dig tool (why this chip runs against Quad9, not Cloudflare)

Family filter: blocked vs allowed#

Run live: isitdns.net/#dig?preset=family-filter

dig @8.8.8.8 protonvpn.com A
dig @185.228.168.168 protonvpn.com A

Google returns protonvpn.com's real address. CleanBrowsing Family returns NXDOMAIN with an RPZ-tagged SOA (cleanbrowsing.rpz.noc.org.), the fingerprint of a manufactured "no" rather than the real zone (measured 2026-07-17; block lists and results change over time and by vantage). A content filter doesn't inspect the HTTP traffic; it refuses to resolve the name, so the client never gets an IP to connect to. Block lists commonly cover more than adult content: VPN and proxy providers are frequent entries too, which is why protonvpn.com is the example here.

DNS-level filtering is easy to bypass: pointing the client at any other resolver defeats it, which is why it's a first line of defense, not a strong control.

See also: encrypted DNS (a filter-bypass mechanism)

Ad blocking: AdGuard vs Google#

Run live: isitdns.net/#dig?preset=ad-blocking-adguard

dig @8.8.8.8 doubleclick.net A
dig @94.140.14.14 doubleclick.net A

Google returns doubleclick.net's real address, its own ad-serving infrastructure. AdGuard returns NOERROR with a single A 0.0.0.0, a sinkhole, tagged with Extended DNS Error 17, "Filtered" (RFC 8914 §4.18), the standards-track way for a resolver to say "I blocked this on purpose." The browser gets an answer, fails to connect, and no traffic reaches the ad server. Block lists change; if you see a real IP back from AdGuard, two causes to check: the domain has cycled off its list, or something on your network path is intercepting port 53 before it reaches 94.140.14.14.

See also: when it's DNS

Ad blocking: Control D vs Google#

Run live: isitdns.net/#dig?name=googlesyndication.com&qtype=A&resolver=google, and Control D

dig @8.8.8.8 googlesyndication.com A
dig @76.76.2.2 googlesyndication.com A

Same sinkhole mechanism as AdGuard, a different resolver and a different target: googlesyndication.com delivers Google AdSense ads on third-party sites. Google's 8.8.8.8 returns the real, geo-load-balanced address. Control D's 76.76.2.2 (its free ads-and-tracking profile) returns A 0.0.0.0; the sibling IP 76.76.2.0 is Control D's free unfiltered profile and returns a real address for the same name, which is the point of a per-profile resolver: the IP you query is the policy.

See also: when it's DNS

ANY and RFC 8482#

Run live: isitdns.net/#dig?name=cloudflare.com&qtype=ANY&resolver=trace (trace mode walks root to cloudflare.com's own nameservers, so the answer comes straight from the authoritative)

dig -4 @ns3.cloudflare.com cloudflare.com ANY +dnssec

;; ANSWER SECTION:
cloudflare.com.   3600   IN   HINFO   "RFC8482" ""
cloudflare.com.   3600   IN   RRSIG   HINFO 13 2 3600 ...

dig -4 @ns1.google.com google.com ANY

;; ANSWER SECTION:
google.com.   300   IN   A       142.251.214.110
google.com.   300   IN   AAAA    2607:f8b0:4007:80c::200e
google.com.   300   IN   MX      10 smtp.google.com.
google.com.   300   IN   TXT     "v=spf1 include:_spf.google.com ~all"
google.com.   60     IN   SOA     ns1.google.com. dns-admin.google.com. ...
google.com.   345600 IN   NS      ns1.google.com.

ANY used to mean "every record you have," which made it a DNS amplification weapon: a small spoofed query returns the whole record set at the victim's address. RFC 8482 §4 lets an authoritative reply with one minimal HINFO "RFC8482" "" record instead, collapsing the amplification (Cloudflare's minimal response measures 124 bytes on the wire, EDNS included). The RFC permits this; it does not require it, so Cloudflare returns the minimal HINFO and Google returns the full set for the same query type. Query the authoritative directly, since a recursive resolver can answer ANY from whatever it already has cached for that name.

Cloudflare's own recursive (1.1.1.1) goes further and refuses ANY outright: NOTIMP with EDE 21, "Not Supported" (RFC 8914 §4.22). That's the recursive's policy, a different layer from what the authoritative above chose to do.

What replaced ANY for zone enumeration: AXFR where the operator allows it, or ask for each type you need.

See also: RFC 8482 · Cloudflare: "RFC8482 - Saying goodbye to ANY"

Compare all (MX)#

Run live: isitdns.net/#dig?name=example.com&qtype=MX&resolver=all

# Conceptually:
for r in 1.1.1.1 8.8.8.8 9.9.9.9 94.140.14.14; do
  dig -4 @$r example.com MX
done

Cloudflare, Google, Quad9 and AdGuard return the same MX records: none of the four filters example.com, so agreement among the four is the expected result, and disagreement is the finding (mid-propagation, anycast split, a broken zone). What differs is latency, and that's per-vantage: the fastest resolver in someone else's benchmark isn't necessarily fastest from your network. The SPA can also run each resolver over IPv4 and IPv6 in parallel; a difference between the two on the same resolver usually means a routing or anycast asymmetry worth investigating.

See also: DNS fundamentals

See also#

• the DNS wiki: the full reference layer behind these live examples
• nslookup and dig: the tool-fundamentals page
• dig flag reference: every flag explained
• isitdns.net/#dig: the front-page dig tool