BIND 10 #1244: NSEC support in isc::auth::Query

[BIND 10 Development]

#1244: NSEC support in isc::auth::Query
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  vorner                             |                Status:  accepted
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111025
                  Component:         |            Resolution:
  b10-auth                           |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  6
Feature Depending on Ticket:         |           Total Hours:  0
  Datasrc refactoring                |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 I've looked into BIND 9's NSEC implementation referring to Section
 3.1.3 of RFC4035 to see how we can handle this task.  I propose
 the following breakdown.

 1. Prepare additional (and updating) primitives in the underlying data
 source.
   - We need to handle CNAME + wildcard case separately from non wildcard
     CNAME.  This is a bit ad hoc, but I propose adding a new result
 status,
     WILDCARD_CNAME.
   - DNAME + wildcard is also tricky, but as described in rfc2672bis,
     this usage is now discouraged.  My suggestion is to leave this case
     "undefined", at least for now.  (But checking what happens in tests
     would be a good idea anyway)
   - It looks like we should treat empty (non terminal) wildcard case
     from other WILDCARD_NXRRSET.  I propose adding a new result status,
     WILDCARD_EMPTY.
   - in ZoneFinder::find(), we need another option "NO_WILDCARD", which
     disables wildcard matching.

 The rest of the subtasks are to update auth::Query per the result code.

 2. Handle normal NXRRSET case.
    This is the easiest one.  This case corresponds to Section 3.1.3.1
    and normal (non wildcard) empty non terminal case of Section
    3.1.3.2 of RFC4035.  Just add the returned NSEC to the authority
    section, and done.

 3. Handle NXDOMAIN case.
    This case corresponds to Section 3.1.3.2 of RFC4035. find() returns
    the first NSEC of 3.1.3.2.  We should then perform another find()
    with the NO_WILDCARD option for the best possible wildcard name.
    See BIND 9's bin/named/query.c:query_addwildcardproof() function
    to identify that wildcard name.  Then perform find() with
    NO_WILDCARD again, which should result in NXDOMAIN, and add the
    returned NSEC to the authority section.

 4. Handle WILDCARD_EMPTY case.
    This case corresponds to Section 3.1.3.2 of RFC4035 for the empty
    wildcard case.  find() returns the *second* NSEC of 3.1.3.2.  So we
    should fetch the first NSEC that proves there's no exact matching
    name for the query name.  Perform find() with NO_WILDCARD, which
    should result in NXDOMAIN, and add the returned NSEC.

 5. Handle WILDCARD and WILDCARD_CNAME cases.
    This case corresponds to Section 3.1.3.3 of RFC4035.  In this case
    we should add an NSEC that proves there's no exact matching name
    for the query name.  The algorithm is the same as case #4.

 6. Handle WILDCARD_NXRRSET case.
    This case corresponds to Section 3.1.3.4 of RFC4036.  find()
    returns the first NSEC of 3.1.3.4.  So we should add an NSEC that
    proves there's no exact or closer non-wildcard match.  It should
    actually be equal to the result of find() with NO_WILDCARD for the
    original query name.

 Subtask 2 has no dependency.  Subtasks 3-6 depend on task subtask 1,
 but 3-6 themselves are independent from any others.

 This ticket is now mostly a meta ticket, but if we parallelize the sub
 tasks, there will be some duplicate code (basically, the developers
 should watch each other's work to minimize the redundancy), so after
 finishing all, in this ticket we should probably do some
 unification/cleanup.

 I'm going to create tickets for the subtasks, and release this ticket.

 p.s. In the above description I may be wrong in some details.  Please
 do not blindly trust the descrption.  Whoever takes this task should
 read the protocol spec carefully, and should also refer to the
 behavior of other implementations (and the implementation itself).

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