Subject: [dnsext] RRSIGs in additional section

From: Kumar Ashutosh <[email-masked]>
Date: Fri, 15 Nov 2013 12:07:36 +0000

Hi

As per RFC 4035 section 3.1.1
When placing a signed RRset in the Additional section, the name server MUST also place its RRSIG RRs in the Additional section. If space does not permit inclusion of both the RRset and its associated RRSIG RRs, the name server MAY retain the RRset while dropping the RRSIG RRs.  If this happens, the name server MUST NOT set the TC bit solely because these RRSIG RRs didn't fit.

If such a response is received by a caching resolver it may Cache the RRSet in additional section without their RRSIGs and subsequent queries from this resolver might be responded without RRSIGs. Will not this lead to issues? Is there any update to this behaviour? Am I missing something?

Thanks
Ashu

---

From: Tony Finch <[email-masked]>
Date: Fri, 15 Nov 2013 14:06:05 +0000

Kumar Ashutosh <[email-masked]> wrote:
> When placing a signed RRset in the Additional section, the name server
> MUST also place its RRSIG RRs in the Additional section. If space does
> not permit inclusion of both the RRset and its associated RRSIG RRs, the
> name server MAY retain the RRset while dropping the RRSIG RRs.  If this
> happens, the name server MUST NOT set the TC bit solely because these
> RRSIG RRs didn't fit.

This is sort-of consistent with RFC 2181 (depending on whether you view
the RRSIG as part of the RRset or not):

9. The TC (truncated) header bit

   The TC bit should be set in responses only when an RRSet is required
   as a part of the response, but could not be included in its entirety.
   The TC bit should not be set merely because some extra information
   could have been included, but there was insufficient room.  This
   includes the results of additional section processing.  In such cases
   the entire RRSet that will not fit in the response should be omitted,
   and the reply sent as is, with the TC bit clear.  If the recipient of
   the reply needs the omitted data, it can construct a query for that
   data and send that separately.

   Where TC is set, the partial RRSet that would not completely fit may
   be left in the response.  When a DNS client receives a reply with TC
   set, it should ignore that response, and query again, using a
   mechanism, such as a TCP connection, that will permit larger replies.

> If such a response is received by a caching resolver it may Cache the
> RRSet in additional section without their RRSIGs and subsequent queries
> from this resolver might be responded without RRSIGs.

No. See RFC 2181 section 5.4.1:

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 15 Nov 2013 09:16:08 -0500

> If such a response is received by a caching resolver it may Cache the RRSet in additional section without their RRSIGs and subsequent queries from this resolver might be responded without RRSIGs. W…

Good question, answer is no 
but that is complicated and requires full compliance with RFC2181. 

Just some back ground, 
	a)  The motivation for this text is to avoid TCP connection just because not all the additional data did fits in the packet.

	b) in many cases the resolver has the same data in its cache thus the additional section is redundant. 

	c) RFC2181 says resolver MUST not promote cached data to higher criticality by placing it in an earlier section than it came in, 
	thus cached additional data section MUST NOT be placed in answer section. In this case the resolver needs to recurse before answering.

	d) DNSSEC packets are big and we need to make them smaller thus suppressing out-of-zone glue is a good idea (minimall-answers) 

Olafur