Opened 7 years ago

Closed 5 years ago

#2668 closed defect (wontfix)

DATASRC_DATABASE_FIND_TTL_MISMATCH (BIND 9 is different from BIND 10)

Reported by: jreed Owned by:
Priority: medium Milestone: Remaining BIND10 tickets
Component: data source Version: bind10-old
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: Medium
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 4 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

I noticed my logs had:

2013-01-25 07:13:17.494 WARN  [b10-auth.datasrc/41040] DATASRC_DATABASE_FIND_TTL_MISMATCH TTL values differ in sqlite3_zone.sqlite3 for elements of bind10.isc.org./IN/RRSIG, setting to 3600

2013-01-25 07:13:17.495 WARN  [b10-auth.datasrc/41040] DATASRC_DATABASE_FIND_TTL_MISMATCH TTL values differ in sqlite3_zone.sqlite3 for elements of bind10.isc.org./IN/RRSIG, setting to 3600

The server is a slave. The master is a BIND 9 server. The other BIND 9 slaves don't modify the TTL.

There are some TTLs in the set that are 7200.

The log message should be modified to point to specification and explain clearly why BIND 10 is different than BIND 9.

Subtickets

Change History (14)

comment:1 Changed 7 years ago by jinmei

This seems to be a bug, not just a disparity with BIND 9. I suspect
BIND 10 considered RRsets for different covered type the same single
RRset and incorrectly unifies the TTLs.

comment:2 follow-up: Changed 7 years ago by jreed

RFC2181:5.2

A bug in BIND 9 to serve it?

Looks like BIND 10 did right thing by setting to the value of the lowest TTL in the RRSet.

comment:3 in reply to: ↑ 2 Changed 7 years ago by jinmei

Replying to jreed:

RFC2181:5.2

A bug in BIND 9 to serve it?

Looks like BIND 10 did right thing by setting to the value of the lowest TTL in the RRSet.

No, BIND 9 is correct (if this is what I guessed). It looks like a
bug of BIND 10. See the last para of Section 3 of RFC4034.

   The TTL value of an RRSIG RR MUST match the TTL value of the RRset it
   covers.  This is an exception to the [RFC2181] rules for TTL values
   of individual RRs within a RRset: individual RRSIG RRs with the same
   owner name will have different TTL values if the RRsets they cover
   have different TTL values.

comment:4 Changed 7 years ago by jwright

  • Defect Severity changed from N/A to Medium
  • Milestone changed from New Tasks to Next-Sprint-Proposed

comment:5 Changed 7 years ago by jinmei

  • Milestone changed from Previous-Sprint-Proposed to Next-Sprint-Proposed

comment:6 Changed 7 years ago by jelte

  • Milestone changed from Next-Sprint-Proposed to Sprint-20130305

comment:7 Changed 7 years ago by jelte

  • Milestone Sprint-20130305 deleted

yeah the question is how much special-case we want for rrsig queries (the information is stored in the database but lost currently in the data-collection methods, also note that the in-mem version currently returns no signatures at all for rrsig queries)

Moving to backlog until we decide on an approach, as discussed in the sprint planning meeting. Remind me to move it back soonish :)

comment:8 Changed 7 years ago by jinmei

is this related to RRSIG queries? I thought it could happen for, e.g., a type ANY
query.

comment:9 Changed 7 years ago by jinmei

  • Milestone set to Next-Sprint-Proposed

comment:10 Changed 7 years ago by jinmei

  • Milestone changed from Previous-Sprint-Proposed to Next-Sprint-Proposed

comment:11 Changed 7 years ago by jinmei

I'm not sure (or don't remember) what was controversial about this, so I'm trying it
again...

comment:12 Changed 7 years ago by jinmei

  • Milestone set to Next-Sprint-Proposed

comment:13 Changed 6 years ago by tomek

  • Milestone set to Remaining BIND10 tickets

comment:14 Changed 5 years ago by tomek

  • Resolution set to wontfix
  • Status changed from new to closed
  • Version set to old-bind10

This issue is related to bind10 code that is no longer part of Kea.

If you are interested in BIND10/Bundy framework or its DNS components,
please check http://bundy-dns.de.

Closing ticket.

Note: See TracTickets for help on using tickets.