Subject: DNSSECbis clarifications: QTYPE ANY & "DNSSEC RRSets"

From: Peter Koch <[email-masked]>
Date: Mon, 20 Feb 2006 18:41:06 +0100

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 ANY query with DO=0.

pro:

  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 below.

  "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.

con:

  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 side
     MUST strip any authenticating DNSSEC RRs from the response but MUST
     NOT strip any DNSSEC RR types that the initiating query explicitly
     requested.

  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.

Opinions?

-Peter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Feb 2006 09:46:31 +1100

> Thanks for all the responses so far. Just in case my question was neutral,
> i support the "pro" side. The "con" may identify himself :-)
> 
> On Tue, Feb 21, 2006 at 09:26:01AM +1100, Mark Andrews wrote:
> 
> > 	I'd expect to see the records in the answer section as a
> > 	client making a * query is expecting to see records it
> > 	cannot decode.  A RFC 1035 client cannot decode a RP record
> > 	but no one here would say don't sent the RP.
> > 
> > 	I would not expect to see the DNSSEC records in the additional
> > 	and authority sections.
> 
> Agreed, my question was imprecise. Suggest the follwoing text for the
> clarifications document:
> 
> ANY queries
> 	When responding to ANY queries without the DO bit set, authoritative
> 	or recursive servers MUST include in the answer section any DNSSEC
> 	specific RRSets that are present for QNAME, just as they would for
> 	any other RR type.
> 	Since no DNSSEC processing is requested, DNSSEC specific RRSets MUST
> 	NOT appear in the authority or additional section.
> 
> > 	Asking * to a parent server with a signed parent zone of a
> > 	signed child zone gets more interesting.  DS, NSEC and RRSIG
> 
> Yes, that touches a whole lot of different issues.
> 
> > 	should be in the answer section.  There should be a referral
> > 	containing the NS records.  Again there would be not DNSSEC
> 
> Which NS RRSet in this case?

	The referral should have the NS RRset from the parent zone.
	This assumes that the server is not server both the parent
	and child zone.  When serving both you would have the DS
	and NSEC from the parent + RRSIGS as well as all the records
	from the child zone.

	While RFC 103[45] only called the address records glue,
	both the NS RRset and associated address records are glue.
	They both really belong on the child zone and are only in
	the parent zone to allow you to find the child zone.
 
	Mark

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]