Re: RRSIGs in additional section

On Nov 15, 2013, at 7:07 AM, Kumar Ashutosh <[email protected]> wrote:

> 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?
>  

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

_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext