BIND 10 #1899: performance issue of SQLite3 "iterate" query (w/ or w/o NSEC3)

BIND 10 Development do-not-reply at isc.org
Mon Oct 1 11:03:37 UTC 2012


#1899: performance issue of SQLite3 "iterate" query (w/ or w/o NSEC3)
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  muks
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20121009
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:  data   |           Sub-Project:  DNS
  source                             |  Estimated Difficulty:  6
                   Keywords:         |           Total Hours:  0
            Defect Severity:         |
  Medium                             |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => muks


Comment:

 Hello

 The code looks mostly OK, but I'm not completely sure about the design.

 First, is it true there can be only one NSEC3 per name? There can be
 multiple
 NSEC3 chains (with different parameters). That could in theory intersect
 at
 some places. I'm not saying our code works correctly at the moment with
 this,
 but hardcoding the brokenness it into the DB seems wrong. However, I don't
 think these NSEC3s would be collated to the same RRset anyway, because
 they
 are, effectively, each in its own  namespace and not talking to each
 other.

 Also, the restriction in your case is even stronger. The table contains
 both
 NSEC3s and their RRSIGs, which won't be possible in your case.

 And then, when iterating, the NSEC3s and their RRsets may want to end up
 together (I didn't look at how we collate RRsets with their RRSIGs, but I
 believe they should meet).

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


More information about the bind10-tickets mailing list