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