BIND 10 #152: Xfrin changes TTL for RRSIGs

BIND 10 Development do-not-reply at isc.org
Tue Apr 20 08:02:45 UTC 2010


#152: Xfrin changes TTL for RRSIGs
--------------------------+-------------------------------------------------
 Reporter:  jreed         |        Owner:     
     Type:  defect        |       Status:  new
 Priority:  major         |    Milestone:     
Component:  Unclassified  |   Resolution:     
 Keywords:                |    Sensitive:  0  
--------------------------+-------------------------------------------------

Comment(by jinmei):

 > I can't reproduce this behavior.

 Okay, I now understand the problem.

 MessageImpl::parseSection() combines RRSIGs with different covering types
 into a single RRset, adjusting TTLs.  That's why all RRSIGs have the TTL
 of the RRSIG covering NSEC (which, in you case, should be the smallest
 TTL).

 Meanwhile, RRset::addRRsig() resets RRSIG's TTL to the TTL of the covered
 RRset (I suspect this is a questionable behavior, but that's a separate
 issue).  This is why I couldn't reproduce it via dig.

 We'll have to fix it, but I'm not sure about the best way to fix this.
 BIND 9 treats RRSIG as a special case in many places of the code and it
 has a lot of conditional statements like:

 {{{
 if (rdtype == dns_rdatatype_rrsig) {
     /* do some special thing with its "covers", etc */
 }
 }}}

 We could do the same thing, but IMO this is very error prone.  I'll think
 about other possibilities to see whether we can handle all RRtypes
 (including RRSIG) more transparently, while still dealing with the special
 semantics of some special RRtypes.

 I'll think about it more.

-- 
Ticket URL: <http://bind10.isc.org/ticket/152#comment:2>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list