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

BIND 10 Development do-not-reply at isc.org
Wed Jan 18 07:43:30 UTC 2012


#1584: auth::Query NSEC3 support: Wildcard answer case
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |                       Status:  new
            Priority:  major         |                    Milestone:  Next-
           Component:  b10-auth      |  Sprint-Proposed
           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
-------------------------------------+-------------------------------------
 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.

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


More information about the bind10-tickets mailing list