skip to content

In a DNSSEC lookup, what do the DO, AD and CD bits each signal, and which party sets each one?

level: middleimportance: must knowfreq 32%

answer

  1. one EDNS flag, two header flags
  2. DO rides in the OPT record
  3. AD is the responder's claim
  4. CD hands checking back to the asker

basics

~20 s

DO, in the EDNS0 OPT record, is set by a querier to request DNSSEC records. AD is set by a validating resolver on answers it verified. CD is set by a querier to say it will do the checking itself.

solid answer

~50 s

`DO` (DNSSEC OK, RFC 3225) is the most significant bit of the extended flags in the EDNS0 `OPT` pseudo-record: a querier sets it to say it can accept `RRSIG`, `DNSKEY` and `NSEC` records, and a security-aware recursive resolver sets it on every upstream query whatever its client sent. `AD` (Authentic Data) and `CD` (Checking Disabled) are header bits that DNSSEC added. `AD` belongs to the responder: a validating resolver must not set it unless every RRset in the Answer and Authority sections is authentic, and RFC 6840 adds that it should set it only when the query carried `DO` or `AD`. `CD` belongs to the querier: it tells the resolver to skip enforcing its own validation, so the resolver returns the data even when it would have rejected them. `DO` does not switch validation on; a validating resolver checks either way.

go deeper

for a junior

Recall the three names and their homes: DO in the EDNS0 OPT record, AD and CD in the header. DO asks for signatures, AD reports a verified answer, CD asks the resolver not to filter.

for a middle

Explain who owns each bit: the querier sets DO and CD, the validating resolver sets AD. Show that the resolver sets DO upstream regardless of the client and strips signatures for a DO-clear client.

for a senior

Show the operational edges: AD is an unsigned header claim, CD returns data the resolver would have rejected, and a validating forwarder sets CD upstream so an upstream SERVFAIL does not hide data from its own check.

for a principal

Weigh where the trust decision should sit: a central resolver's AD verdict is cheap for clients but needs a trusted path, while CD-based validation at the edge costs complexity and gains independence from upstream policy.

## Three bits in two places DNSSEC needs three signals: ask for signatures, report that they were checked, and say "give me the data, I will check it myself". They are three bits in two places. | Bit | Where it lives | Who sets it | What it says | Specified in | |---|---|---|---|---| | `DO` (DNSSEC OK) | extended flags of the EDNS0 `OPT` pseudo-record | the querier: a stub or a resolver | "I can accept DNSSEC records in the reply" | RFC 3225, RFC 4035 §3.2.1 | | `AD` (Authentic Data) | the DNS message header | the responder: a validating resolver | "I consider every RRset in Answer and Authority authentic" | RFC 4035 §3.2.3, RFC 6840 §5.7-5.8 | | `CD` (Checking Disabled) | the DNS message header | the querier | "Do not filter on your validation; I take responsibility" | RFC 4035 §3.2.2, §4.6 | RFC 4035 states the split directly: the **CD bit is controlled by resolvers** (the asking side) and the **AD bit is controlled by name servers** (the answering side). ## DO: asking for the evidence Without `DO`, a security-aware server leaves the authenticating records out of its answer. With it, the server should include the `RRSIG`, `DNSKEY`, `NSEC` and `DS` records the reply needs. - **The recursive resolver always sets it upstream.** RFC 3225 and RFC 4035 §3.2.1 require the resolver side of a security-aware recursive server to set `DO` on its own queries regardless of the client's `DO`, because it needs the signatures to validate for every client. - **It strips for clients that did not ask.** If the client's query had `DO` clear, the server side removes the authenticating DNSSEC records from the reply, but not record types the client explicitly asked for, such as a query for `DNSKEY`. - **It is echoed but not trusted.** RFC 3225 says the `DO` bit of the query is copied into the response; RFC 6840 §5.6 tells resolvers to ignore `DO` in responses because some implementations do not copy it. - **Absence proves nothing.** RFC 3225 warns that a reply to a `DO` query with no DNSSEC data must not be read as "this zone has no security information": the reply may be forged, or the query altered on the way. - **It is not a validation switch.** A validating resolver checks responses whether or not the client set `DO`; RFC 4035 §4.2 lists the exceptions to validation, and a clear `DO` is not one of them. A client that never sets `DO` is still protected from bogus data; it simply never sees the signatures. ## AD: the resolver's claim RFC 4035 §3.2.3 says the server side **must not** set `AD` unless it considers all RRsets in the Answer and Authority sections authentic, and **should** set it when the Answer RRsets and any relevant negative-response records are authentic. RFC 6840 §5.8 narrows this for compatibility: set `AD` only when the request carried `DO` or `AD`. Two details trip people up: 1. **`AD` in a query.** RFC 4035 §4.6 told resolvers to clear `AD` when composing queries. RFC 6840 §5.7 later gave it a meaning: a set `AD` in a query says "I understand the `AD` bit and want it in the reply", which lets a client get the verdict without asking for the bulky DNSSEC records via `DO`. 2. **`AD` is not signed.** An `RRSIG` covers an RRset, never the message header. Anyone on the path can set or clear `AD`, so RFC 4035 §4.6 makes a resolver disregard `AD` and `CD` in a response unless it arrived over a secure channel or the resolver is explicitly configured to trust it. An authoritative server does not validate its own data, and RFC 4035 §3.1.6 lets it treat that data as authentic only when the zone arrived by secure means and the behaviour is explicitly configured. ## CD: taking the checking back The resolver copies `CD` from the query into the response and passes it to its resolver side, which then need not authenticate the data. RFC 4035 §3.2.2 says that with `CD` set the resolver **should return the data even if its own policy would reject it**, and §5.5 says the full response goes back to a client that set `CD`, while one that did not gets `RCODE 2` (SERVFAIL). - A **validating stub should set `CD`** (RFC 4035 §4.9.2), because otherwise the recursive server's policy may withhold data the stub would accept: the stub may have a trust anchor the resolver lacks, or the resolver's clock may be wrong. - A **non-validating stub should not set `CD`** unless an application asks; it depends on the resolver's check. - RFC 6840 §5.9 tells **validating resolvers to set `CD` on every upstream query**, so a forwarding chain does not hide data behind an upstream SERVFAIL, at the cost (its §7) of no longer benefiting from stricter rules or a fuller set of trust anchors upstream. ## One lookup, bit by bit 1. A stub asks a validating resolver for `www.example.com A` with `DO` clear, `AD` set and `CD` clear. 2. The resolver queries upstream with `DO` set, collects the `RRSIG` and `DNSKEY` records and validates. 3. On success it answers `NOERROR` with the `A` records, the `AD` bit set, and no signatures, because the client did not set `DO`. 4. Had validation failed, this client would get SERVFAIL; with `CD` set it would get the records back.

  • Why does a recursive resolver set DO on its upstream queries even when the client's query had DO clear?
    It must validate for every client and cache one copy of the data, so it always needs the `RRSIG` and `DNSKEY` records. RFC 3225 and RFC 4035 §3.2.1 require `DO` on its own queries regardless of the client's bit, and require it to strip the authenticating records from the reply to a `DO`-clear client while leaving any record type that client explicitly asked for. The cached data are not modified.
  • Why should a validating resolver that forwards through another validating resolver set CD on its upstream queries?
    If it does not, the upstream validator's verdict replaces its own: a bogus answer comes back as SERVFAIL, which the downstream can neither check against its own trust anchors nor diagnose, and a cached SERVFAIL may persist for up to five minutes (RFC 2308). RFC 6840 §5.9 therefore says to set `CD` on every upstream query. Its §7 names the cost: no benefit from stricter upstream rules or extra upstream trust anchors.
  • What does a set AD bit in a DNS query mean?
    RFC 4035 §4.6 originally said to clear `AD` in queries. RFC 6840 §5.7 redefined a set `AD` in a query as a signal that the requester understands the `AD` bit and wants it in the response. That lets a client receive the resolver's verdict without setting `DO` and pulling in the signatures, and RFC 6840 §5.8 has validating resolvers set `AD` only when the query carried `DO` or `AD`.

saying these in an interview costs you the question

  • Setting the DO bit is how a client asks the resolver to validate.
  • The AD bit is protected by the zone's signatures, so any client can trust it.
  • CD means the client does not want DNSSEC records in the reply.
  • Every authoritative server for a signed zone sets AD on its answers.
  • A reply to a DO query with no RRSIGs proves the zone is unsigned.