BIND 10 #1178: NSEC3 support in new data source

[BIND 10 Development]

#1178: NSEC3 support in new data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  kevin_tes
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  minor  |  Sprint-20111122
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => kevin_tes


Comment:

 Some points on the task breakdown above:

 * Many of the responses require a "closest encloser" or "closest provable
 encloser" proof which returns up to two RRs.  I would suggest that one of
 the tasks be to write the code that will retrieve these RRs.  This can
 then be used in the tasks listed above.
 * As you suggest, the code needs the hashing function in order to operate;
 that may already be available in a usable form in the code.  If not, it
 needs to be written/modified.  (Included in this task may also be the
 selection of the NSEC3PARAM record - it is allowable for there to be
 multiple NSEC3PARAM records - and hence NSEC3 chains - in the zone.)
 * The "Fourth: Wildcard no data" section implies there are two separate
 cases (two sentences start with "If").  In fact it is one case - the
 response should include the closest encloser proof and the NSEC3 RR that
 matches the wildcard.
 * Is the sixth case "Wildcard CNAME answer" really a separate case from
 the fifth case (wildcard answer) - CNAME is not mentioned as a special
 case in [http://tools.ietf.org/html/rfc5155 RFC 5155] except in the
 context of ensuring that the CNAME bit is not set in the Type Bit Maps
 field.

 I have been through [http://tools.ietf.org/html/rfc5155 RFC 5155] and have
 summarised its [wiki:Rfc5155DetailedRequirements detailed requirements]. I
 think there are two other cases (listed in the section on "Inclusion of
 NSEC3 Records in Responses from Authoritative Server"):

 * Special no data case when the QTYPE is a DS record and there is no NSEC3
 record. ([http://tools.ietf.org/html/rfc5155#section-7.2.4 RFC 5155
 section 7.2.4])
 * Queries for NSEC3 RRs ([http://tools.ietf.org/html/rfc5155#section-7.2.8
 RFC 5155 section 7.2.8])

 > If no dispute about the above, i will generate 13 tickets:
 Finally, perhaps one ticket for each feature (instead of one for find()
 and one for process()) as the two are closely linked.

 A step-by-step approach is sensible, although to avoid people getting in
 each other's way (as each change is likely to make detailed changes to the
 find() and process() methods), we might find it easier to do these tickets
 sequentially.

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