BIND 10 #1431: NSEC3: closest provable encloser proof

BIND 10 Development do-not-reply at isc.org
Wed Jan 18 07:17:38 UTC 2012


#1431: NSEC3: closest provable encloser proof
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  stephen                            |                Status:  new
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20120124
                   Priority:  major  |            Resolution:
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  6
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  NSEC3  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 After considering the whole picture of supporting NSEC3 in in-memory
 data source, I now propose the following for this ticket:

 Define the interface of a new method of `ZoneFinder`, findNSEC3, and
 implement it in auth/tests/query_unittest.cc:MockZoneFinder.

 The description of the method is:

 {{{#!c++
 std::pair<bool, ConstRRsetPtr>
 ZoneFinder::findNSEC3(const Name& name, bool recursive);
 }}}

 It searches the (conceptual) auxiliary table of zone that stores NSEC3
 RRsets for exact or covering NSEC3 for the given name.
 if recursive is true, it will continue the search up toward the
 zone apex until it finds a provable enclosure NSEC3.
 If it cannot find a provable enclosure even at the apex, or
 if it cannot find any NSEC3 when recursive is false, it throws.

 It returns std::pair<bool, ConstRRsetPtr>.  The first element is
 true if the found NSEC3 is an exact match (this should always be
 the case when recursive is true); it's false if it's a covering
 NSEC3.  The second element points to the found NSEC3 RRset.  This
 must never be null.

 We'll need to implement this for in memory version of the finder, but
 it's better to do that after #1574 and #1575.  Also, by providing it
 in the auth tests we can start developing the higher level support
 (i.e. updates to auth::Query) independently from lower level support.

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


More information about the bind10-tickets mailing list