/flags/dns/dig-cd-checking-disabled
dig +cd: bypass DNSSEC validation to tell SERVFAIL from a broken signature
- tool
- DNS
- command
- dig
- flag
- +cd (+cdflag)
- default
- +nocdflag (the CD bit is not set, so a validating resolver validates DNSSEC answers)
dig +cd example.com sets the CD (Checking Disabled) bit in the query. The BIND manual describes it as requesting "the server to not perform DNSSEC validation of responses". A validating resolver then returns the data it obtained even if the signatures are invalid. That makes +cd the quickest test for one of the most confusing DNS failures: a resolver answering SERVFAIL for a domain that otherwise looks fine. If the same query succeeds with +cd, DNSSEC validation is what fails.
The two-query test
dig example.com A # SERVFAIL from your validating resolver?
dig +cd example.com A # records come back: validation is the problem
dig +cd +dnssec example.com A # look at the RRSIG validity dates and key tags
dig +dnssec example.com DS # does the parent's DS match the zone's DNSKEY?Interpreting the results
| Plain query | With +cd | Likely cause |
|---|---|---|
| NOERROR | NOERROR | Healthy (or the zone is unsigned) |
| SERVFAIL | NOERROR with data | DNSSEC validation failure: expired RRSIG, DS/DNSKEY mismatch, bad rollover |
| SERVFAIL | SERVFAIL | Not DNSSEC: authoritative servers unreachable or misconfigured |
| NXDOMAIN | NXDOMAIN | The name does not exist |
When validation is the cause, applications see generic resolution errors, for example getaddrinfo EAI_AGAIN in Node.js, even though the records exist. Response codes are listed in DNS RCODEs.
Related header flags
| Flag | Set by | Meaning |
|---|---|---|
| RD | Client (default on; +norecurse clears it) | Recursion desired |
| CD | Client (+cd) | Do not validate DNSSEC for this query |
| DO | Client (+dnssec) | Include DNSSEC records |
| AD | Resolver | The answer was validated as secure |
| AA | Authoritative server | The answer comes from an authoritative server |
Pitfalls
- Non-validating resolvers ignore it. If the resolver does not validate at all,
+cdchanges nothing and SERVFAIL has other causes. - Caches. A resolver may have cached the failure; repeat after the negative-cache time or test several resolvers.
- Next step. Fetch signatures and keys with dig +dnssec, and query the authoritative servers directly with dig +norecurse to see what they publish.
FAQ
What does it mean when dig +cd works but plain dig returns SERVFAIL?
The resolver can fetch the records but they fail DNSSEC validation: expired signatures, a DS record that matches no DNSKEY, or a broken key rollover. The zone operator must fix the signing; clients cannot work around it safely.
Should applications set the CD bit?
No. Disabling validation removes the protection DNSSEC provides. Use +cd only to diagnose; applications should rely on a validating resolver.
What if dig +cd also fails?
Then validation is not the cause: the authoritative servers may be unreachable, lame or misconfigured. Query them directly with @server +norecurse to find which one fails.