is it dns? / wiki ← back to the live monitor

dig flag reference

Flags that actually change behavior. Skipping the ones that are aliases for default.

Anatomy of a dig answer#

Ask the zone's own authoritative nameserver and read the reply top to bottom:

dig example.isitdns.net @coleman.ns.cloudflare.com
; <<>> DiG 9.18.39 <<>> example.isitdns.net @coleman.ns.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9214
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.isitdns.net.        IN    A

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

;; Query time: 5 msec
;; SERVER: 172.64.35.64#53(coleman.ns.cloudflare.com) (UDP)
;; WHEN: Mon Jun 15 02:19:35 UTC 2026
;; MSG SIZE  rcvd: 64

Block by block:

The invocation

; <<>> DiG 9.18.39 <<>> example.isitdns.net @coleman.ns.cloudflare.com

What you ran, echoed back. The @coleman.ns.cloudflare.com means "ask this server directly" instead of your system resolver.

The header

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9214
  • opcode: QUERY is an ordinary lookup.
  • status: NOERROR is the rcode, and the single most important field. NOERROR means the name exists. NXDOMAIN means it does not. SERVFAIL means the server broke or DNSSEC validation failed. REFUSED means it will not answer you (an authoritative server answers REFUSED when asked about a zone it does not host).
  • id: 9214 ties this response to your request. It is random per query, so yours will differ.

The flags

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
  • qr marks this as a response, not a query.
  • aa (authoritative answer) says the answering server is the source of truth for this zone, not a cache. Cloudflare's nameservers set it here, and so does any conventional authoritative server (BIND, NSD, Knot).
  • rd (recursion desired) was set in your request and echoed back in the response. dig sets it by default.
  • ra (recursion available) is absent: an authoritative-only server will not recurse on your behalf. The WARNING line is dig pointing out that mismatch (you asked for recursion, the server does not offer it), and it is normal when querying an authoritative server directly. A recursive resolver's answer shows the opposite shape: rd ra and no aa. If you name an authoritative server and get back rd ra without aa, something on the path intercepted your query and answered from a cache.
  • The four counts say how many records sit in each section below: 1 question, 1 answer, 0 authority, 1 additional.

The OPT pseudosection

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232

Not a real record. This is the EDNS0 envelope where each side advertises the UDP payload size it can accept (udp: 1232 here is what Cloudflare's nameservers advertise) and the DNSSEC-OK bit. It is the one record counted in ADDITIONAL. See anatomy-of-a-query for a deeper walkthrough of the EDNS0 section.

The question

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

Exactly what you asked, echoed back: the name, class IN (Internet), and type A. If this does not match what you meant to ask, your shell or resolver rewrote it.

The answer

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

The record itself, in five fields: name, TTL, class, type, data. The 300 is the TTL in seconds. Straight from the authoritative server it is always the zone's full value; ask a recursive resolver instead and you see it counting down as the record sits in the cache. 192.0.2.1 is a documentation address (RFC 5737), so it resolves but never routes.

The footer

;; Query time: 5 msec
;; SERVER: 172.64.35.64#53(coleman.ns.cloudflare.com) (UDP)
;; WHEN: Mon Jun 15 02:19:35 UTC 2026
;; MSG SIZE  rcvd: 64

Diagnostics, not DNS data: the round-trip time, which server answered (a Cloudflare anycast address on port 53, over UDP), the timestamp, and the response size in bytes.

Fields that change every run: id, Query time, WHEN, and (behind anycast) which SERVER address answers. The TTL counts down only in cached answers; from the authoritative server it is the full zone value every time. Fields that are stable and real: status, the flags, the question, and the answer data.

Output volume#

FlagWhat it does
+shortOne line per record, just the data: best for scripts
(default)Full sections: question, answer, authority, additional, plus timing
+noall +answerOnly the answer section, but still formatted
+statsForce the stats footer (default on, but useful with +noall)
+nostatsHide the stats footer
+comments / +nocommentsToggle the ;; header lines

Which server to ask#

FlagWhat it does
@serverAsk server (IP or hostname). Default is /etc/resolv.conf.
-4IPv4 only
-6IPv6 only
+tcpForce TCP (default UDP with TCP retry on TC)
+ignoreKeep a truncated UDP answer instead of retrying over TCP (good for testing the UDP path). +notcp does not do this: it only picks the initial transport, and the TC retry still happens.
+tlsDoT (requires kdig from knot-dnsutils, or BIND dig 9.18+)
+https=/dns-queryDoH (requires kdig from knot-dnsutils, or BIND dig 9.18+)

What kind of query#

FlagWhat it does
+norec / +nordflagClear the RD bit: ask the server not to recurse for you. Recursive resolvers vary: 1.1.1.1 answers RD=0 queries from cache with NOERROR (and SERVFAIL with an EDE note, "no local cache to fulfill non recursion (RD=0) request", on a cache miss), while 8.8.8.8 returns SERVFAIL for RD=0 queries even when the name is cached. Authoritative servers answer RD=0 normally, since that is exactly what recursive resolvers send them. Useful for peeking at what a resolver has cached.
+traceWalk the delegation chain from root yourself. Skips the resolver's cache.
+nssearchFind the SOA at each authoritative NS and compare serials: quick replication-health check
-x <IP>Reverse lookup. Shorthand for dig PTR <reversed-IP>.in-addr.arpa. See ptr.

DNSSEC#

FlagWhat it does
+dnssecSet the DO (DNSSEC OK) bit: server may return RRSIG records alongside the answer. See dnssec.
+cdSet CD (Checking Disabled): ask the resolver to skip DNSSEC validation. Useful for seeing the raw answer when validation is breaking things.
+adSet the AD bit in your query, asking the resolver to signal whether it validated the answer. The resolver sets AD in the response if the answer is DNSSEC-validated. Modern dig sets this bit by default, so you rarely need to type it.
+nocryptoIn delv, suppress the full cryptographic dump

EDNS / buffer#

FlagWhat it does
+bufsize=NAdvertise an EDNS0 UDP buffer of N bytes. Default 1232 in modern dig.
+nsidAsk the server to identify itself via EDNS NSID: useful when querying anycast pools. Requires the server to support and advertise NSID; many public resolvers do not respond with one.
+subnet=<CIDR>Send EDNS Client Subnet (the resolver-injects-client-location feature)

Useful combinations#

Minimal scriptable lookup

dig +short A example.isitdns.net
192.0.2.1
nslookup -type=A example.isitdns.net

nslookup can not produce bare one-line output like +short; use dig +short in scripts.

Ask an authoritative nameserver directly

dig @coleman.ns.cloudflare.com example.isitdns.net
nslookup example.isitdns.net coleman.ns.cloudflare.com

nslookup's -norecurse flag is the equivalent of +norec: both clear the RD bit. Authoritative servers answer RD=0 queries normally (RD=0 is what recursive resolvers send them), so neither flag changes the answer here. The RD bit matters when you query a recursive resolver and want cache-only behavior instead of a fresh recursion.

See the aa bit with a resolver-style query (+norec)

The anatomy example above already shows aa: Cloudflare's nameservers answer authoritatively for the zones they host, and any conventional authoritative server (BIND, NSD, Knot) sets the bit the same way. Add +norec and the query becomes the exact shape a recursive resolver sends an authoritative server, RD clear and all:

dig @pns1.isitdns.net probe.isitdns.net SOA +norec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ...
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

probe.isitdns.net. 300 IN SOA pns1.isitdns.net. hostmaster.isitdns.net. \
  2026061512 7200 3600 1209600 300

The SOA serial increments each time the zone is updated, so the value you see will differ from what is shown here.

Heads up: the probe.isitdns.net zone and its nameservers pns1/pns2 are being rebuilt and do not currently answer; a lookup today returns NODATA from the parent zone. The exchange above is kept as the teaching example, and any conventional authoritative server (BIND, NSD, Knot) reproduces it.

aa appears because pns1.isitdns.net is the authoritative source for the probe.isitdns.net zone. ra is absent because a conventional auth server does not offer recursion. +norec clears the RD bit in the query; pns1 still answers, and so do Cloudflare's authoritative nameservers for their own zones. RD=0 is the normal resolver-to-auth query shape (it is exactly what 1.1.1.1 sends coleman and hera when it resolves example.isitdns.net for you), so no authoritative server treats it as unusual.

On a network that intercepts port 53 (captive portals, some home routers), a @server query is answered by the interceptor, not the named server. You may see only rd ra without aa. That reflects your network, not pns1's behavior. Verify via DoH if you suspect interception (see Confirm DNSSEC validation below).

The nslookup equivalent clears RD the same way:

nslookup -norecurse -type=SOA probe.isitdns.net pns1.isitdns.net

Walk the delegation chain yourself

dig +trace isitdns.net

nslookup can not walk the delegation chain. Use dig.

Confirm DNSSEC validation (AD bit)

The local system resolver may strip the AD bit. Use a trusted validating resolver explicitly, or verify via DoH:

dig +ad @1.1.1.1 isitdns.net
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

ad in the flags means the resolver cryptographically validated the answer. isitdns.net is fully signed and anchored (DS keytag 2371, ECDSAP256SHA256 at .net). See dnssec.

You can also verify via DoH, which reports the AD bit reliably regardless of local resolver behavior:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=isitdns.net&type=A'
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,...}

"AD":true confirms validation. See dnssec-troubleshooting for when AD is false.

nslookup can not show the AD bit. Use dig.

Test a deliberately broken DNSSEC zone

dig @1.1.1.1 dnssec-failed.org
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: ...

SERVFAIL from a validating resolver means validation failed. Use +cd to bypass validation and see the raw answer:

dig +cd @1.1.1.1 dnssec-failed.org

nslookup can not show the AD bit or set the CD bit usefully. Use dig.

Confirm the UDP path works (no TCP fallback)

DNS over UDP caps at 512 bytes by default; EDNS0 raises that ceiling. When a response would exceed the advertised buffer size, the server sets the TC (truncated) bit and the client retries over TCP/53. Use +ignore to keep the truncated UDP answer instead of retrying (not +notcp, which only picks the initial transport and does not prevent the retry). Use +bufsize=512 to advertise a small buffer so a large response actually triggers truncation. Use +tcp to force TCP regardless.

To observe a real TC bit, you need a response that exceeds the buffer. DNSKEY records for RSA-signed zones are large enough to trigger it. dnssec.works uses RSA keys whose DNSKEY response exceeds 512 bytes:

dig +ignore +bufsize=512 DNSKEY dnssec.works
dig +tcp DNSKEY dnssec.works

The first query returns with TC set and a truncated response. The second returns the full answer over TCP.

nslookup -type=DNSKEY dnssec.works
nslookup -vc -type=DNSKEY dnssec.works

The -vc flag (virtual circuit) forces TCP in nslookup. There is no equivalent of +ignore +bufsize=512 in nslookup.

Quick zone-replication check

dig +nssearch isitdns.net

nslookup has no +nssearch equivalent. To compare serials manually, query each nameserver for the SOA:

nslookup -type=SOA isitdns.net coleman.ns.cloudflare.com
nslookup -type=SOA isitdns.net hera.ns.cloudflare.com

Windows PowerShell

nslookup can not walk the delegation chain (no +trace) and its DNSSEC support shows raw record data only. On Windows, PowerShell offers a structured alternative:

Resolve-DnsName isitdns.net
Resolve-DnsName cloudflare.com -DnssecOk | Where-Object { $_.Type -eq 'RRSIG' }

Resolve-DnsName does not have a -DnsOverHttps switch. For DoH on Windows use a browser or a dedicated DoH client.

kdig extras#

kdig (from knot-dnsutils) adds DoT/DoH support and slightly nicer output:

kdig @1.1.1.1 +tls isitdns.net
kdig @1.1.1.1 +https=/dns-query isitdns.net

The -d flag shows the TLS handshake details:

kdig @1.1.1.1 +tls -d isitdns.net

nslookup can not do DoT or DoH. Use kdig for encrypted transport, or curl with the DoH endpoint.

delv for DNSSEC#

delv annotates each answer with its validation state, which dig does not do natively. It uses its own built-in trust anchor (the IANA root KSK) rather than relying on the resolver.

Signed zone, chain verified end to end:

delv cloudflare.com @1.1.1.1
; fully validated
cloudflare.com.  300  IN  A  104.16.132.229
cloudflare.com.  300  IN  A  104.16.133.229
...

Deliberately broken zone, validation fails:

delv dnssec-failed.org @1.1.1.1
;; resolution failed: failure

isitdns.net is signed and anchored (DS at .net), so delv validates the full chain:

delv isitdns.net @1.1.1.1
; fully validated
isitdns.net.  300  IN  A  104.21.56.211
isitdns.net.  300  IN  A  172.67.155.242

Skip validation (insecure mode):

delv -i cloudflare.com @1.1.1.1
; answer not validated

A common trap: delv +cd does not skip validation. The +cd (Checking Disabled) bit only tells the upstream resolver not to validate; delv still runs its own validation against its built-in trust anchor and prints ; fully validated. On a broken zone, delv +cd retrieves the invalid data the resolver would have blocked and reports the failure itself (;; resolution failed: broken trust chain), which is exactly what makes it useful for debugging. To make delv itself stop validating, use -i (insecure mode), which reports ; answer not validated.

delv has no nslookup equivalent. On Windows, install the BIND utilities to get delv, or use Resolve-DnsName -DnssecOk to surface RRSIG records (PowerShell does not report a validation verdict, only the raw signature data). See dnssec-troubleshooting for validation debugging workflows.

See also: dig-along · when-its-dns · nslookup-and-dig · dnssec · dnssec-troubleshooting · dot-doh · anatomy-of-a-query · query-types · ptr