BIND 10 #1349: Update "Authoritative Query Logic" design to support NSEC3

[BIND 10 Development]

#1349: Update "Authoritative Query Logic" design to support NSEC3
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jiangchao
  kevin_tes                          |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20111108
                   Priority:         |            Resolution:
  critical                           |             Sensitive:  0
                  Component:         |           Sub-Project:  DNS
  b10-auth                           |  Estimated Difficulty:  5
                   Keywords:         |           Total Hours:  0
            Defect Severity:         |
  Medium                             |
Feature Depending on Ticket:  1178   |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jiangchao):

 Replying to [comment:4 kevin_tes]:
 > Add the Name Error,No data, Wildcard answer,Wildcard no data and
 referrals to unsigned subzone query logic for NSEC3.
 > The Wiki web page is at:
 >
 > http://bind10.isc.org/wiki/AuthServerQueryLogic

 1:
 if qtype is DS, search the available zones for the zone which is the
 nearest ancestor to QNAME's parent. for example, if qname is c.example.com
 and type is DS, search the zone which is the nearest ancestor of
 example.com.

 2.c:
 If we were looking up the original QNAME of the query, clear the AA bit in
 the reply. Place the NS records for the subzone into the authority section
 of the reply. check whether a DS record was found, if so, add ds and its
 signatures to authority secion, else if the zone is secured and support
 nsec, go to 2.c.Ⅰ;else if the zone is secured and support nsec3 goto
 2.c.Ⅱ; else, go to setp7.
 2.c.Ⅰ: add nsec rr(MUST be exist) and its signautre matching the
 delegation ns name to authority section.
 2.c.Ⅱ: if the nsec3 rr matching the delegation ns name exists, add it and
 its signatures to authority section; else(no matching nsec3 rr), the
 delegated zone must be OPT-OUT, add covered nsec3 rr(opt-out flag must be
 set) and its signature to authority section.

 3.b:
 If an RRset matching QNAME/CNAME is found, add it and its signature to the
 answer section

 3.c:
 If ANY RRset matching QNAME is found, regardless of RRtype, if zone is
 secured, add matching nsec/nsec3 rrset and its signature to authority
 section. goto step 6.

 3.d:
 If any RRsets are found with a name which is a subdomain of QNAME, if the
 zone is secured by nsec, add nsec rr covering qname and its signature to
 authority section; if the zone is secured by nsec3, add nsec3 rr matching
 qname(must exist) to authority section. go to step 6.

 4:
 No match has been found. If zone is secure by NSEC, an covered NSEC RR
 proving that there is no exact match for QNAME,should add those to the
 authority section. 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. then check wildcard match.
 search qname's wildcard name(add "*" to qname's closest enclosure name)
 and qtype: if found, modify the wildcard rrset name to qname and add it
 and its signature to answer section; if wildcard name found but no type
 match, add the nsec3 rr matching wildcard name and its signature to
 authority section; if wildcard name not found, add nsec3 rr covering
 wildcard name to authority section.

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