BIND 10 #1584: auth::Query NSEC3 support: Wildcard answer case

[BIND 10 Development]

#1584: auth::Query NSEC3 support: Wildcard answer case
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:  task   |             Milestone:  Next-Sprint-
                   Priority:  major  |  Proposed
                  Component:         |            Resolution:
  b10-auth                           |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  0
Feature Depending on Ticket:  NSEC3  |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Description changed by jinmei:

Old description:

> This task implements RFC5155 7.2.6 and updates
> ZoneFinder::WILDCARD_CNAME and ZoneFinder::WILDCARD cases of
> Query::process():
>
> - call findNSEC3(recursive = true) for the qname.  It will return
>   the NSEC3 of the provable closest enclosure of the qname, which
>   should also be the immediate ancestor of the wildcard name.
>   DO NOT add it to the authority section; as noted in the RFC,
>   this NSEC3 is not necessary for the wildcard proof.
> - call findNSEC3(recursive = false) for the nsec3.getName() where
>    nsec3 is the RRset returned in the first step.  It will return
>    the NSEC3 covering the next closer of the immediate ancestor of
>    the wildcard.  The result shouldn't be an exact match;
>    otherwise wed' probably return SERVFAIL.
> - add the second NSEC3 to the authority section.
>
> Note: this is not a very efficient way to detect the next closer
> name; it should be possible to get it directly from the RRSIG (that
> should have been provided with the answer) and owner name.  But this
> case would be minor for major NSEC3 users (i.e. TLDs), so
> performance wouldn't be a big issue.
>
> Depends on #1431.

New description:

 (updated based on #1431 discussion)

 This task implements RFC5155 7.2.6 and updates
 ZoneFinder::CNAME and ZoneFinder::SUCESS (with RESULT_WILDCARD flag)
 cases of Query::process():

 - call findNSEC3(qname, recursive=true).  It will return (in
   closest_proof) the NSEC3 for the provable closest encloser of the
   qname, which should also be the immediate ancestor of the wildcard
   name.  If next_proof is null, it's a run time collision, should
   return SERVFAIL.
   DO NOT add it to the authority section; as noted in the RFC,
   this NSEC3 is not necessary for the wildcard proof.
 - construct the next closer of the closest encloser toward qname
   based on qname and the returned closest_labels in the first step.
   That is, it should be:
   `qname.split(qname.getLabelCount() - closest_labels -1).`
 - call findNSEC3(recursive=false) for the next closer name.
   The result shouldn't be an exact match; otherwise it's a run time
   collision and should result in SERVFAIL.
 - add the second NSEC3 to the authority section.

 Note: this is not a very efficient way to detect the next closer
 name; it should be possible to get it directly from the RRSIG (that
 should have been provided with the answer) and owner name.  But this
 case would be minor for major NSEC3 users (i.e. TLDs), so
 performance wouldn't be a big issue.

 Depends on #1431.

--

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