Below the header and the question, every line dig prints in the answer, authority and additional sections is one resource record (RR) in five columns: owner name, time to live (), class, type and data, the master-file format of (RFC) 1035. This part reads the columns, then the data of the types you meet; the reply as a whole, its blocks and its header have their own parts. Afterwards you can decode each record, tell a cache's countdown from a zone's constant, and follow a chain to the name that earned the status code.

Five columns, six wire fields

On the wire a record has six fields (RFC 1035, section 3.2.1): NAME, "an owner name, i.e., the name of the node to which this resource record pertains"; TYPE and CLASS, two octets each; TTL; RDLENGTH; and RDATA, a variable-length string of octets describing the resource. dig prints five, the data implying its own length, in the master-file order, where "Since type and class mnemonics are disjoint, the parse is unique" (section 5.1): the type is always the last word before the data. The question line has three columns and no TTL (section 4.1.2) and opens with a semicolon because dig prints it as a comment by default (dig manual, +question).

Illustrative, composed in dig's format (BIND 9.20.29 masterdump.c) from an address and the TTL example.com answered with on 2026-10-18:

;; ANSWER SECTION:
example.com.		300	IN	A	104.20.23.154

In practice the class of nearly every query is IN, the Internet (RFC 9499, section 4); the Internet Assigned Numbers Authority () registers IN as 1 and Chaos (CH) as 3 (IANA DNS Parameters, DNS CLASSes), CH surviving for questions about the server itself, such as id.server of type (RFC 4892, section 2).

The TTL: a countdown in a cache, a constant in the zone

The TTL is "a 32 bit unsigned integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded" (RFC 1035, section 4.1.3); section 3.2.1 said signed, which erratum 2130 corrects (RFC 1035 erratum 2130). It runs from 0 to 2147483647 as a maximum, not a mandate (RFC 2181, section 8), with a recommended cap of 604,800 seconds, seven days (RFC 8767, section 4).

Who answered decides what you see: "refresh timers and TTLs for cached data conceptually 'count down', while data in the zone stays with constant TTLs" (RFC 1035, section 6.1.3). Read through a public resolver on 2026-10-18, the CNAME of www.iana.org showed a TTL of 2971 and, 305 seconds later, 2666. The A records in the same answer went from 216 to 300: they had expired and been fetched again, restarting at the zone's 300. Asked the authoritative server, the number never moves. A public anycast resolver is many caches (RFC 4892, section 1).

Addresses and names: A, AAAA, NS and PTR

An A record's data is one 32-bit address in dotted decimal, and a host with several addresses has several A records (RFC 1035, section 3.4.1). An holds one 128-bit IPv6 address in network byte order (RFC 3596, section 2.2).

An NS (name server) record's data names a host that should be authoritative for the class and domain (RFC 1035, section 3.3.11); NS records sit at the top of a zone beside the (RFC 1034, section 4.2.1).

A (domain name pointer) record's data is a name (RFC 1035, section 3.3.12). Under in-addr.arpa each label is one octet of the address, in reverse order (section 3.5): 192.0.2.1 is asked for as 1.2.0.192.in-addr.arpa. IPv6 reverses its 32 hexadecimal digits, one label each, under ip6.arpa (RFC 3596, section 2.5), so 2001:db8::1 becomes 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa, which the IPv6 Toolkit computes.

CNAME: the chain the server follows

A CNAME (canonical name) record's data "specifies the canonical or primary name for the owner. The owner name is an alias" (RFC 1035, section 3.3.1). "If a CNAME RR is present at a node, no other data should be present" (RFC 1034, section 3.6.2), the RRSIG and NSEC records of a signed zone excepted (RFC 4035, section 2.5). Asked an alias for an A record, a server copies the CNAME into the answer and restarts at the canonical name (RFC 1034, section 4.3.2), so the answer carries the chain in order, each record owning the previous record's data (RFC 2308, section 1). Illustrative, with documentation addresses:

;; ANSWER SECTION:
www.example.com.		3600	IN	CNAME	www.example.com.cdn.example.net.
www.example.com.cdn.example.net. 300	IN	A	192.0.2.10
www.example.com.cdn.example.net. 300	IN	A	192.0.2.11

Who you asked decides whether you see the whole chain. A recursive resolver follows it, caching the CNAME and restarting at the canonical name (RFC 1034, section 5.3.3). An authoritative server whose target lies in another zone returns the CNAME and a referral in the authority section (RFC 2308, section 2.1); the second lookup is yours.

The response code () belongs to the chain's end: "The RCODE in the ultimate DNS response MUST BE set based on the final query cycle leading to that response" (RFC 6604, section 3). A chain ending at a missing name gives NXDOMAIN with the CNAMEs still in the answer (RFC 2308, section 2.1); one ending at a name without the asked type gives NOERROR, only CNAMEs in the answer, and an SOA in the authority section (section 2.2).

SOA: seven fields, and what MINIMUM means today

The SOA (start of a zone of authority) record's data is two names and five numbers (RFC 1035, section 3.3.13): MNAME, the primary server; RNAME, the responsible mailbox written as a name, its first label the local part (RFC 1912, section 2.2); SERIAL, the zone's version; REFRESH, RETRY and EXPIRE, the timers of zone transfers; and MINIMUM. Illustrative, composed from example.com's SOA of 2026-10-18, by default and with +multiline +ttlunits (BIND 9.20.29 soa_6.c):

example.com.		1800	IN	SOA	elliott.ns.cloudflare.com. dns.cloudflare.com. 2416374680 10000 2400 604800 1800

example.com.		30m IN SOA	elliott.ns.cloudflare.com. dns.cloudflare.com. (
				2416374680 ; serial
				10000      ; refresh (2 hours 46 minutes 40 seconds)
				2400       ; retry (40 minutes)
				604800     ; expire (1 week)
				1800       ; minimum (30 minutes)
				)

RFC 2308 redefined MINIMUM: "The remaining of the current meanings, of being the TTL to be used for negative responses, is the new defined meaning of the SOA minimum field" (RFC 2308, section 4). A server reporting NXDOMAIN, or a name with no data of the asked type, puts the zone's SOA in the authority section, and "The TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself" (section 3). For example.com both are 1800, so a negative answer lives at most 30 minutes in a cache, and NXDOMAIN alike (section 5).

On 2026-10-18 a missing name under example.com came back NOERROR with the SOA above in the authority section: compact denial of existence answers NODATA instead of NXDOMAIN (RFC 9824, section 1); a missing name under .invalid came back NXDOMAIN with the root's SOA, because "Users MAY assume that queries for 'invalid' names will always return NXDOMAIN responses" (RFC 6761, section 6.4).

MX and SRV: preference, priority, weight, and the dot that means none

An (mail exchange) record's data is a 16-bit PREFERENCE and an EXCHANGE host (RFC 1035, section 3.3.9). A sending mail server sorts by preference, lower first, and randomises among equals (RFC 5321, section 5.1). A single record 0 . is the null MX, no mail accepted, and "A domain that advertises a null MX MUST NOT advertise any other MX RR" (RFC 7505, section 3).

An (Server Selection) record, type 33, is owned by a name of the form _Service._Proto.Name and holds Priority, Weight, Port and Target (RFC 2782, The format of the SRV RR). "A client MUST attempt to contact the target host with the lowest-numbered priority it can reach" (Usage rules), and among equal priorities "Larger weights SHOULD be given a proportionately higher probability of being selected" (Usage rules). A Target of . means the service is decidedly not available (The format of the SRV RR). The RFC's own example:

_foobar._tcp    SRV 0 1 9 old-slow-box.example.com.
                SRV 0 3 9 new-fast-box.example.com.
                SRV 1 0 9 sysadmins-box.example.com.

The third box is tried only when both priority-0 boxes fail, and weights 1 and 3 do not split traffic 1 to 3: the draw is a uniform random number from 0 to the sum inclusive, so the weight-3 box is chosen 3 times in 5 in this order and 4 times in 5 listed first (RFC 2782 erratum 8120).

TXT: strings of at most 255 octets

A TXT (text) record's data is one or more character-strings, each a length octet followed by that many octets, hence at most 255 octets each (RFC 1035, sections 3.3 and 3.3.14). dig prints each string in double quotes, separated by one space, escaping quotes, backslashes and non-printable bytes (BIND 9.20.29 rdata.c); the quotes are presentation, not data. A long value arrives as several strings in one record, and for Sender Policy Framework () "the record MUST be treated as if those strings are concatenated together without adding spaces" (RFC 7208, section 3.3). Automatic Certificate Management Environment () validation puts its token in a TXT record under _acme-challenge (RFC 8555, section 8.4), the value the ACME dns-01 TXT computer computes.

CAA: flags, tag, value

A (Certification Authority Authorization) record prints as flags tag "value": a number from 0 to 255, lowercase letters and digits, and a quoted value (RFC 8659, section 4.1.1; BIND 9.20.29 caa_257.c). By the numbering convention "the Flags value 1 means that bit 7 is set, while a value of 128 means that bit 0 is set" (section 4.1): 128 marks a property a certification authority () must understand or not issue. The tags are issue, issuewild for wildcard names, which takes precedence, and iodef, a mailto, http or https address for reports (sections 4.2 to 4.4). The lookup "climbs the DNS name tree from the specified label up to, but not including, the DNS root" (section 3). In the RFC's examples the second forbids every issuer (section 4.2) and the third every CA that has not implemented tbs (section 4.5):

certs.example.com         CAA 0 issue "ca1.example.net"
nocerts.example.com       CAA 0 issue ";"
new.example.com           CAA 128 tbs "Unknown"

The types of the DNS Security Extensions (), RRSIG, DNSKEY, DS, NSEC and their relatives, print in the same five columns when you ask with +dnssec; DNSSEC records in dig output reads them.

When a correct-looking answer fails

A CNAME at the apex. The apex holds the SOA and NS records (RFC 9499, section 7), and "A CNAME record is not allowed to coexist with any other data" (RFC 1912, section 2.4). The fixes are address records at the apex or an HTTPS record with SvcPriority 0, whose "primary purpose of AliasMode is to allow aliasing at the zone apex, where CNAME is not allowed" (RFC 9460, section 2.4.2).

An alias where a host is required. "The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias" (RFC 2181, section 10.3): no address then comes in the additional section (section 10.3), and NS records pointing at a CNAME conflict with servers (RFC 1912, section 2.4).

Stale records after a change. A cache keeps the old record until its countdown ends, so lowering the TTL afterwards helps nobody: "If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following the change" (RFC 1034, section 3.6). A negative answer is cached the same way, for up to min(MINIMUM, SOA TTL).

Misread TXT and SRV. A multi-string TXT joined with spaces, or SRV weights read across priorities, are reading errors, not zone errors.

How to see it

# Zone TTLs from an authoritative server (illustrative address), cache countdown from your resolver
dig @192.0.2.53 example.com A
dig example.com A
# One type at a time; the SOA in the verbose form with units
dig example.com MX
dig -t TXT example.com
dig +multiline +ttlunits example.com SOA
# Only the record lines: name, TTL, class, type, data
dig +noall +answer example.com NS
# Reverse: dig builds 1.2.0.192.in-addr.arpa and asks for PTR
dig -x 192.0.2.1
# A real NXDOMAIN, and a server's identity in class CH
dig nonexistent.invalid A
dig @192.0.2.53 -c CH -t TXT id.server

dig @server name type is the typical invocation; without a type dig asks for A, without a server it reads /etc/resolv.conf (dig manual, Simple Usage). -x builds the reverse name and sets type PTR (Options, -x); +noall +answer leaves only the record lines (Examples); how dig parses a command has its own part.

Paste the default single-line output into the dig output explainer: it splits each record into its five columns, names the data fields of SOA, MX, SRV and CAA, and flags a NOERROR answer with no records as NODATA. The dig command builder composes the commands above, class CH and -x included; the nslookup output explainer reads nslookup's labelled form.

What to remember

  • A record line is five columns, owner name, TTL, class, type and data; the wire's RDLENGTH is implied, and the type is always the last word before the data.
  • A TTL is an unsigned count of seconds, at most 2147483647; it counts down in a cache and stays constant in the zone.
  • A CNAME owner holds no other data; the server copies the CNAME into the answer and restarts at its target, and the RCODE belongs to the chain's last name.
  • The SOA's MINIMUM is the negative-caching TTL, bounded by the SOA's own TTL, for NXDOMAIN and NODATA alike.
  • MX preference and SRV priority: lower first; SRV weight shares only among equal priorities, and a target of . means no service.
  • A TXT string holds at most 255 octets; several strings in one record join with no space, and the quotes are dig's, not data.
  • CAA flags 128 means critical; the tags are issue, issuewild and iodef, and the lookup climbs towards the root.

Sources