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:  accepted
                       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      |
-------------------------------------+-------------------------------------

Comment (by kevin_tes):

 As RFC 5155(DNS Security (DNSSEC) Hashed Authenticated Denial of
 Existence)suggests that, there are eight case for NSEC3 Hashed
 Authenticated Denial of Existence.

 First:    Name error
      If zone is secure and support NSEC3, NSEC3 RRs proves both that QNAME
 does not exist and that a
    wildcard that could have matched QNAME also does not exist,add those to
 the authority section.[7.2.2]

 Second:   No data
      Include the NSEC3 RR that matches QNAME to the authority
 section.[7.2.3]

 Third:  Referrals to unsigned subzone
    If there is an NSEC3 RR that matches the delegation name, then that
 NSEC3 RR MUST be included in the response.
    If the zone is Opt-Out, then there may not be an NSEC3 RR
 corresponding to the delegation.  In this case, the closest provable
 encloser proof MUST be included in the response.  The included NSEC3  RR
 that covers the "next closer" name for the delegation MUST have  the Opt-
 Out flag set to one. [7.2.7]


 Fourth:  Wildcard no data
      If the zone is secured by nsec3, add nsec3 rr matching QNAME's
 closest enclosure name and nsec3 rr covering QNAME's next closer name and
 their signatures to authority section.
      If wildcard name found but no QTYPE match, add the nsec3 rr matching
 wildcard name and its signature to authority section;

 Fifth:   Wildcard answer
      If the zone is secured by nsec3, add nsec3 rr matching QNAME's
 closest enclosure name and nsec3 rr covering QNAME's next closer name and
 their signatures to authority section.
      If  wildcard name and QTYPE found, modify the wildcard rrset name to
 Qname and add it and its signature to answer section;

 Sixth:   Wildcard cname answer
      If the zone is secured by nsec3, add nsec3 rr matching QNAME's
 closest enclosure name and nsec3 rr covering QNAME's next closer name and
 their signatures to authority section.
      If the wildcard node match the QNAME and it contains data of RRtype
 CNAME, copy the CNAME RRset into the answer section, but set its owner to
 be QNAME.

 Since NSEC3 RR was stored by it corresponding hash codes,it should add a
 ticket to done this work when the zone supports NSEC3,it can generate the
 hash(QNMAE),to query.


 Both Query::process() and find() need update.

 If no dispute about the above, i will generate 13 tickets:

 First:    Name error, both Query::process(),find() need to update ,there
 add 2 tickets.
 Second:   No data,both Query::process(),find() need to update ,there add 2
 tickets.
 Third:    Referrals to unsigned subzone,both Query::process(),find() need
 to update ,there add 2 tickets.
 Fourth:   Wildcard no data,both Query::process(),find() need to update
 ,there add 2 tickets.
 Fifth:    Wildcard answer,both Query::process(),find() need to update
 ,there add 2 tickets.
 Sixth:    Wildcard cname answer,both Query::process(),find() need to
 update ,there add 2 tickets.

 Total:13 tickets.

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