dig +dnssec: request RRSIG records and check whether a DNS answer is signed
- tool
- DNS
- command
- dig
- flag
- +dnssec (+do)
- default
- +nodnssec (the DO bit is not set, so servers omit DNSSEC records)
dig +dnssec example.com A sets the DNSSEC OK (DO) bit in the EDNS OPT record of the query; the BIND manual describes it as requesting "that DNSSEC records be sent". A server that supports DNSSEC then includes the RRSIG signatures alongside the requested records (and NSEC/NSEC3 proofs for negative answers). Without the DO bit, servers leave all DNSSEC records out, so a plain dig cannot tell you whether a zone is signed. The DO bit is defined in RFC 3225; the records and the validation process in RFC 4035.
Typical commands
dig +dnssec example.com A # A records plus RRSIG, header flags
dig +dnssec +noall +answer example.com A # only the records and signatures
dig +dnssec @ns1.example.com example.com DNSKEY # the zone's public keys from the authoritative server
dig +dnssec example.com DS @a.gtld-servers.net # the delegation signer record in the parent zone
dig +dnssec nonexistent.example.com # NSEC/NSEC3 proof of non-existenceWhat to look for in the output
| Item | Where | Meaning |
|---|---|---|
| ad flag | flags line in the header | The resolver validated the answer as secure |
| do flag | OPT PSEUDOSECTION (EDNS: ... flags: do) | The query asked for DNSSEC records |
| RRSIG records | Answer section, after the records they sign | Signature, algorithm, key tag, validity dates |
| DNSKEY / DS | Answers to those query types | Keys in the zone and their hash in the parent |
| NSEC / NSEC3 | Authority section of negative answers | Signed proof that a name or type does not exist |
The validity period in an RRSIG (inception and expiration timestamps) is a common source of outages: when signatures expire because re-signing stopped, validating resolvers return SERVFAIL for the whole zone.
Diagnosing a validation failure
dig example.comreturns SERVFAIL from a validating resolver.dig +cd example.comreturns the records: validation is the problem, not the zone's availability; see dig +cd.dig +dnssec @ns1.example.com example.com DNSKEYanddig +dnssec example.com DSshow whether the DS in the parent matches a key in the zone and whether the signatures are current.
Response codes such as SERVFAIL are explained in DNS RCODEs, and the record types in DNS record types.
Pitfalls
- Large responses. DNSSEC answers are big and may be truncated over UDP; dig retries over TCP, but a firewall blocking TCP 53 breaks it.
- The DO bit is not validation. dig itself does not validate; use
delvfrom BIND for local validation, or rely on theadflag from a validating resolver. - Propagation checks. After key rollovers, check several resolvers as in check DNS propagation.
FAQ
How do I know if the answer was validated?
Look at the flags line of the header. A validating resolver sets the ad (authenticated data) flag when every record in the answer was validated as secure. +dnssec makes the resolver return the RRSIG records; the ad flag is the validation result.
Why are there no RRSIG records with +dnssec?
The zone is not signed, or the resolver strips DNSSEC data. Query the authoritative server directly with @ns1.example.com +dnssec to see whether the zone itself publishes signatures.
Is +do the same as +dnssec?
Yes. The BIND manual lists +dnssec, +do, +nodnssec and +nodo as the same option: it sets the DNSSEC OK (DO) bit in the EDNS OPT record of the query.