Inside a DNS packet

Filed under Notes on July 17, 2026 · updated

The DNS message format field by field: the 12-byte header and its flags, the question, the answer records, and EDNS. Plus the record types a domain actually holds. Part 2 of a DNS series.

Every DNS query and reply has the same shape on the wire: a 12-byte header full of flags, then up to four sections (question, answer, authority, additional). For the lookup that sends these messages, start with how DNS works.

The message

This is a real response to hugosibony.com A, drawn as its five parts. Click any field to see what it does.

DNS message
response hugosibony.com A 104.21.86.12

Click any field to inspect it.

Header 12 bytes · 6 × 16-bit words
Flags 16-bit 0x8180

The second word packs eleven control fields into 16 bits: one QR bit, a 4-bit Opcode, six single-bit flags (AA, TC, RD, RA, Z, AD, CD) and a 4-bit RCODE. Click any sub-field below to see it on its own.

Question QDCOUNT = 1
Answer ANCOUNT = 2 · resource-record layout
hugosibony.com. 300 IN A 104.21.86.12 hugosibony.com. 300 IN A 172.67.213.189
Authority NSCOUNT = 0

Empty. This is a direct answer, so no NS records are attached. On a referral, this section would list the nameservers to ask next.

Additional ARCOUNT = 1

The lone additional record is the EDNS(0) OPT pseudo-record (TYPE 41). It advertises the sender’s UDP payload size and carries the DO (DNSSEC OK) bit, modern DNS’s extension mechanism (RFC 6891).

The flags carry the message’s whole personality: QR (question or answer), RD and RA (was recursion asked for, is it offered), AA (authoritative), RCODE (NOERROR, NXDOMAIN, SERVFAIL), and the DNSSEC bits AD and CD.

The records

The answer section is a list of resource records. A gets the headlines, but a domain holds a handful of record types, each with a job: mail routing, aliases, delegation, text for verification, DNSSEC keys.

DNS record types

The building blocks of a zone. Pick a type to see its numeric code, defining RFC, and a real-shaped example.

Everyday
Mail & text
Infrastructure
DNSSEC

A

TYPE 1 RFC 1035

Maps a name to an IPv4 address.

example hugosibony.com. 300 IN A 104.21.86.12

AAAA

TYPE 28 RFC 3596

Maps a name to an IPv6 address.

example hugosibony.com. 300 IN AAAA 2606:4700:3030::6815:560c

CNAME

TYPE 5 RFC 1035

Canonical-name alias, points a name at another name.

example www.github.com. 3600 IN CNAME github.com.

MX

TYPE 15 RFC 1035

Mail exchanger for the domain, with a priority.

example example.com. 3600 IN MX 10 mail.example.com.

TXT

TYPE 16 RFC 1035

Arbitrary text, used for SPF, DKIM and domain verification.

example example.com. 3600 IN TXT "v=spf1 include:_spf.example.com ~all"

NS

TYPE 2 RFC 1035

Delegates a zone to its authoritative nameservers.

example hugosibony.com. 21600 IN NS brad.ns.cloudflare.com.

SOA

TYPE 6 RFC 1035

Start of authority, the zone's primary NS, admin email, serial, timers, and the minimum TTL used for negative caching.

example hugosibony.com. 1800 IN SOA brad.ns.cloudflare.com. dns.cloudflare.com. 2407153759 10000 2400 604800 1800

PTR

TYPE 12 RFC 1035

Reverse lookup, maps an IP back to a name (in-addr.arpa).

example 1.2.0.192.in-addr.arpa. IN PTR host.example.com.

SRV

TYPE 33 RFC 2782

Locates a service, its host and port.

example _sip._tcp.example.com. IN SRV 10 60 5060 sipserver.example.com.

CAA

TYPE 257 RFC 8659

Declares which CAs may issue certificates for the domain.

example example.com. IN CAA 0 issue "letsencrypt.org"

HTTPS

TYPE 65 RFC 9460

Service binding for HTTPS (ALPN and hints like ECH), lets clients skip a round trip.

example hugosibony.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint="104.21.86.12,172.67.213.189"

OPT

TYPE 41 RFC 6891

EDNS(0) pseudo-record, not real zone data. Lives in the Additional section, advertises UDP payload size and carries the DO (DNSSEC OK) bit.

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

DS

TYPE 43 RFC 4034

Delegation Signer, a hash of a child zone's DNSKEY, published in the parent to build the DNSSEC chain of trust.

example example.com. 3600 IN DS 370 13 2 BE74359954660069D5C63D200C39F5603827D7DD02B56F120EE9F3A86764247C

DNSKEY

TYPE 48 RFC 4034

A zone's DNSSEC public key.

example example.com. 3600 IN DNSKEY 257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjjnopKl+GqJxpVXckHAeF+KkxLbxIL...

RRSIG

TYPE 46 RFC 4034

A DNSSEC signature over an RRset.

example example.com. 3600 IN RRSIG A 13 2 3600 20240201000000 20240101000000 12345 example.com. J5A6...==

Authenticity: DNSSEC

Nothing above proves an answer is genuine. A resolver on the path could forge one, and a plain lookup would never notice. DNSSEC fixes that with signatures. Each zone signs its records with a private key and publishes the signature as an RRSIG and the public key as a DNSKEY. The parent zone vouches for that key with a DS record, so trust chains from the root down to the name. A validating resolver checks the chain and sets the AD bit in the header when it holds.

DNSSEC proves an answer is authentic; it does not hide it. Confidentiality is a separate job, done by encryption.

References

DNS series

  1. How DNS works
  2. Inside a DNS packet (this post)
  3. Encrypting DNS
  4. How malware abuses DNS

Practical companion: Which resolver to choose.

Last updated on
-- views