BIND 10 #1217: Error in automatically updating TTLs that do not match in an RRset
BIND 10 Development
do-not-reply at isc.org
Thu Sep 8 09:10:00 UTC 2011
#1217: Error in automatically updating TTLs that do not match in an RRset
-------------------------------------+-------------------------------------
Reporter: jelte | Owner:
Type: defect | Status: new
Priority: major | Milestone: New
Component: data source | Tasks
Sensitive: 0 | Keywords:
Sub-Project: DNS | Defect Severity: N/A
Estimated Difficulty: 0 | Feature Depending on Ticket:
Total Hours: 0 | Add Hours to Ticket: 0
| Internal?: 0
-------------------------------------+-------------------------------------
In our new datasource code, we automatically update the TTL of an RR if we
are adding it to an RRset with a different TTL. This is fine in general,
but we should not do it blindly; there may be more, but at least in the
case of an RRSIG 'rrset' we shouldn't do it; RRSIGS for the same name can
have a different TTL.
For direct queries this is not much of a problem; we refuse direct RRSIG
queries currently, and for covered types the TTL of the covered set is
used.
It would be a problem with AXFR out though (or, lower-level, the zone
iterators). If we want to be as strict as possible, we should look at
whether the covered types are equal too before modifying the TTL of RRSIG
RRs. Or not check TTL for RRSIG at all.
PS. Also played around with this for a bit, current AXFR IN modifies TTLs
badly as well (though it gets fixed again when querying). Have not tried
current AXFR out, but if the values are wrong in the database already it's
probably not going to be good ;) Anyway with the refactor coming to an
end, we should focus on the new stuff, and I don't think we need to fix
the old one.
--
Ticket URL: <http://bind10.isc.org/ticket/1217>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list