Why should an application not rely on the DNSSEC AD bit from a remote resolver, and what makes that bit trustworthy?
answer
- what the signatures do not cover
- a claim, not a proof
- trust the resolver, trust the path
- or validate it yourself
basics
~20 sAD is a header bit no DNSSEC signature covers, so anyone on the path can set it. Trust it only from a trusted resolver over an authenticated channel (loopback, TSIG, SIG(0), IPsec), or validate on the host instead.
solid answer
~50 sDNSSEC signatures cover RRsets, never the message header, so `AD` (Authentic Data) is just a claim by whoever sent the packet. RFC 4035 §4.6 makes a resolver disregard `AD` and `CD` in a response unless it came over a secure channel or the resolver is explicitly configured to trust them, and §4.9.3 says a stub must not rely on validation done on its behalf unless the data came from a trusted resolver over a secure channel. RFC 4033 names TSIG, SIG(0) or IPsec for that channel and notes it needs integrity and authentication, not confidentiality. That leaves two trust decisions: the path, which channel security fixes, and the resolver itself, which only your own validation removes. Hence the robust designs: a validator on the same host reached over loopback, or a validating stub that sets `DO` and `CD` and checks the signatures itself.
go deeper
Recall that AD is a header flag a resolver sets when it validated the answer, and that no DNSSEC signature covers the header.
Explain RFC 4035's rules: a stub must not rely on AD unless it came from a trusted resolver over a secure channel, and name the channel options TSIG, SIG(0) and IPsec.
Separate the two trust decisions, path and resolver, and choose a design for an application that acts on DNS data: a local validator over loopback or a validating stub using DO and CD.
Weigh central validation, cheap for clients but a shared trust dependency, against validation on each host, independent but costlier to run and keep current with trust anchors.
## What the AD bit is The **Authentic Data (`AD`)** bit is a flag in the DNS message header. A validating resolver sets it on a response when it considers every RRset in the Answer and Authority sections authentic (RFC 4035 §3.2.3), and RFC 6840 §5.8 says it should do so only when the query set `DO` or `AD`. To an application, `AD` looks like exactly what it wants: "this answer passed DNSSEC". The catch is what DNSSEC actually signs. An `RRSIG` record covers one RRset: the records of one name, class and type. No `RRSIG` signs the **message header**, where `AD` lives; only a separate transaction mechanism such as TSIG or SIG(0) protects it. So `AD` carries no cryptographic weight of its own; it is the resolver's report of what it did, and anyone able to alter the message on the way can set it. ## The two trust decisions RFC 4033 says that for a stub to place real reliance on DNSSEC done by its recursive resolver, it must trust **both** the resolver and the communication channel to it. | What could go wrong | Example | What defends against it | |---|---|---| | The path is tampered with | an on-path party forges an answer and sets `AD` | channel security: TSIG, SIG(0), IPsec, or an operating system's local interprocess path | | The resolver is wrong or hostile | it validates with a different policy or trust anchors, or does not validate at all and sets `AD` anyway | only the client's own validation | RFC 4033 is explicit about the second row: for a non-validating stub, the only known defence against the recursive server itself is to perform its own signature validation, at which point it is no longer a non-validating stub. For the channel, RFC 4033 lists TSIG, SIG(0) and appropriate use of IPsec, and notes that **confidentiality is not needed, but data integrity and message authentication are**. An encrypted transport to the resolver also authenticates the path; RFC 8914 lists DNS over HTTPS among secured DNS transactions alongside TSIG and SIG(0). It still says nothing about the resolver's honesty. ## What the RFCs require - **RFC 4035 §4.6:** a resolver must disregard the meaning of `CD` and `AD` in a response unless the response came over a secure channel or the resolver was specifically configured to regard the header bits without one. - **RFC 4035 §4.9.3:** a non-validating stub may look at `AD`, but there may be little practical value in it except as a debugging aid, and it **must not** rely on validation allegedly performed on its behalf unless the data came from a trusted resolver via a secure channel. - **RFC 4035 §4.9.3:** a validating stub should not examine `AD` at all, since it performs its own validation regardless. - **RFC 6840 §5.7:** a client may set `AD` in its query to say it understands the bit, without requesting signatures through `DO`. This changes what the client receives, not how far it can trust it. ## Designs that make AD, or validation, trustworthy When an application makes a security decision from DNS data, for example accepting a key or certificate fingerprint published in DNS, the question "did this pass DNSSEC?" must have a trustworthy answer. Three designs give one: 1. **A validator on the same host.** The application's stub queries a validating resolver over loopback. RFC 4033 mentions operating-system-specific interprocess mechanisms as a channel choice. The path cannot be reached from the network, and the host's operator chooses the resolver's policy and trust anchors. 2. **A validating stub.** The client sets `DO`, so it receives `RRSIG` and `DNSKEY` records (RFC 4035 §4.9.1), and sets `CD`, so the recursive server's own policy does not withhold data the stub would accept (§4.9.2). It then validates from its own trust anchor and never needs `AD`. 3. **A trusted remote resolver over an authenticated channel.** Acceptable when you run the resolver, or trust whoever does, and the channel provides integrity and authentication. You still inherit that resolver's policy and trust anchors. What does **not** work is reading `AD` from a resolver across an untrusted network over plain UDP, however reputable the resolver: the bit you read may not be the bit it sent. ## Reading AD clear `AD` clear is not an alarm. It can mean the zone is unsigned (insecure), the query set neither `DO` nor `AD`, or the resolver does not validate. A bogus answer does not arrive with `AD` clear at all: a validating resolver withholds it and returns SERVFAIL unless the query set `CD`.
- Why does a validating stub resolver set the CD bit on its queries?RFC 4035 §4.9.2 says it should, because otherwise the recursive server answers under its own local policy and may withhold data the stub would accept. §3.2.2 gives examples: the recursive server's clock may be set incorrectly, or the stub may hold a trust anchor for an island of security the server lacks. With `CD` set the stub receives the data and applies its own validation.
- If a stub reaches its resolver over DNS over TLS, can it treat AD as equal to validating itself?No. An authenticated, encrypted channel stops on-path tampering with the header, which covers one of RFC 4033's two conditions. The other is trust in the resolver itself: its validation policy, its trust anchors, whether it validates at all. RFC 4033 says the only known defence against the recursive server is the stub's own signature validation.
saying these in an interview costs you the question
- AD is covered by the answer's RRSIG, so it cannot be forged.
- An encrypted channel to a public resolver equals validating locally.
- The channel to the resolver must be confidential for AD to be trusted.
- AD clear on an answer means the data were forged.
- Setting AD in the query makes the resolver validate more strictly.