This is a discussion on Re: DNSSECbis clarifications: QTYPE ANY & "DNSSEC RRSets" - DNS ; On Feb 20, 2006, at 12:41 PM, Peter Koch wrote: > Colleagues, > > during a discussion at a different venue the question arose whether > or not > the "DNSSEC RRs" should be included in a response to an ...
On Feb 20, 2006, at 12:41 PM, Peter Koch wrote:
> during a discussion at a different venue the question arose whether
> or not
> the "DNSSEC RRs" should be included in a response to an ANY query
> with DO=0.
> section 3 of RFC 4035 (top of page 9) says:
> A security-aware name server that receives a DNS query that
> does not
> include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
> treat the RRSIG, DNSKEY, and NSEC RRs as it would any other
> RRset and
> MUST NOT perform any of the additional processing described
> "treat ... as it would any other RRset" would support ANY
> covering those,
> which is consistent with RFC 3225 (which explicitly listed ANY).
> Also, this would be consistent with RFC 3597, not requiring special
> handling for "unknown" types.
> RFC 4035, 3.2 says:
> 3.2.1. The DO Bit
> The resolver side of a security-aware recursive name server
> MUST set
> the DO bit when sending requests, regardless of the state of
> the DO
> bit in the initiating request received by the name server
> side. If
> the DO bit in an initiating query is not set, the name server
> MUST strip any authenticating DNSSEC RRs from the response but
> NOT strip any DNSSEC RR types that the initiating query
> The important part is the last full sentence.
> Also: the DO bit was introduced to protect "innocent" resolvers from
> DNSSEC RRs they might not expect or understand.
My reading is that the DNSSEC types are included in the ANY response.
In my reading, section 3.2.1 doesn't conflict with the earlier
section. In this case, the DNSSEC types at the qname were
"explicitly requested", and thus fall under the "MUST NOT strip"
clause in that last full sentence.
However, I will readily admit that qtype=ANY and the adverb
"explictly" don't go together terribly well.
Sr. Engineer VeriSign Applied Research
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.