Reading DNS with dig, and an intro to DNSSEC

dig is the tool for observing "who is returning what, right now"

Chapters 4 and 5 covered record types and TTL in theory. In this chapter we use dig to observe those concepts in real responses, and we wrap up with the scope of DNSSEC.

When diagnosing DNS issues, it pays to look at the actual query results before you open the record management UI. dig is the basic tool for that. The important thing is not to memorize many options, but to grasp what the Question / Answer / Authority / Additional sections represent.

$ dig www.example.com A

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

;; QUESTION SECTION:
;www.example.com.        IN      A

;; ANSWER SECTION:
www.example.com.  300    IN      A       203.0.113.10

+trace shows "where you turn"

dig +trace shows the result of walking down from root in order. If you see a suspicious NS somewhere along the delegation path, you can suspect the delegation boundary before looking at record contents.

$ dig +trace www.example.com A
.               518400  IN  NS  a.root-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
example.com.      900   IN  NS  ns1.example.com.
www.example.com.  300   IN  A   203.0.113.10

What DNSSEC protects, and what it does not

DNSSEC is a mechanism that attaches signatures to DNS data and lets a validator follow those signatures. Intuitively, it is for checking "is this RRset really what the zone's owner published, and has it not been tampered with in transit?"

• What it provides: data origin authentication, data integrity
• What it does not provide: confidentiality of query content, encryption of the communication channel itself

If you memorize only the minimum vocabulary, it is these three:

• DNSKEY: the public key used for validation in that zone
• DS: a reference from the parent zone to the child zone's key
• RRSIG: the signature attached to an RRset

Adding +dnssec to dig surfaces the RRSIG records and DNSSEC-related flags in the response. Specifically:

$ dig +dnssec www.example.com A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41203
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096

;; QUESTION SECTION:
;www.example.com.        IN      A

;; ANSWER SECTION:
www.example.com.  300    IN      A       203.0.113.10
www.example.com.  300    IN      RRSIG   A 13 3 300 20260601000000 (
                                         20260501000000 12345 example.com.
                                         abcDEF... )

Pay attention to three things:

• flags: ... ad — Authenticated Data. A flag indicating that the validating side (the recursive resolver) successfully validated the signatures.
• flags: do (inside OPT) — DNSSEC OK. Marks that the client is requesting DNSSEC-aware responses.
• The RRSIG line — the signature itself over the preceding RRset (the A record here). It includes the key tag (12345), the algorithm (13 = ECDSA P-256), the signature expiration (20260601000000), and so on.

You can also use dig DNSKEY or dig DS to observe a zone's public keys or the parent zone's key references directly.

Key takeaways from this chapter

• dig is the first step for observing "what is actually coming back"
• +trace makes delegation boundaries and path anomalies easy to catch
• DNSSEC is a mechanism for tamper detection and data origin authentication, which is separate from encryption