BIND 10 #1431: NSEC3: closest provable encloser proof

[BIND 10 Development]

#1431: NSEC3: closest provable encloser proof
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  stephen                            |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20120124
                   Priority:  major  |            Resolution:
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  6
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  NSEC3  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 The idea of passing a hint through the code seems very reasonable (so we
 won't need to change the interface in future, if we're not going to use
 the hint itself for now too much). However, looking at the code and the
 interface, the fact we are returning the empty NSEC3 RRset to signal it is
 signed with NSEC3 and pass the hint feels like a misuse. It is both not
 obvious and inconsistent with what the NSEC case does.

 What I would propose would be extending the FindResult to include the
 following:
  * Some flags (eg. „zone is signed“, „it is signed with NSEC3“, possibly
 removing the flag of „The result is wildcard“ from the main status and
 including it as a separate flag).
  * A shared_ptr<Hints> (or scoped_ptr, or whatever). The Hints class would
 be either a base class or only declared and a implementation-dependant
 definition would be present in each different data source (the first one
 needs dynamic_cast on the accepting end, but is „by the handbook“, the
 other is little bit misuse, having multiple real types with the same name,
 so it's effectively a hidden anonymous pointer).

 Also, I'd have few code-level details:

 Indentation:
 {{{
 +        /// TBD
 +       virtual FindNSEC3Result
 +        findNSEC3(const isc::dns::Name& name, bool recursive,
 +                  const isc::dns::ConstRRsetPtr known_encloser);
 +
 }}}

 I believe it expects there's NSEC3PARAMS RR in the apex, not NSEC3,
 because the matching NSEC3 is hard to guess without knowing the salt and
 algorithm:
 {{{#!c++
     /// In general, this method expects the zone is properly signed with
 NSEC3
     /// RRs.  Specifically, it assumes at least the apex node has a
 matching
     /// NSEC3 RR.  So the search must always succeed; if the assumption
 isn't
     /// met, \c DataSourceError exception will be thrown
 }}}

 It should be said that the known_encloser should be an RRset coming from
 the same data source as a result of find, not that a user would be allowed
 to construct it directly (eg. the caller shouldn't guess a name, create
 the RRset himself and pass it, because the findNSEC3 method might expect
 it to be a derived class with hints).

 The !DataSourceError exception is usually raised on database errors and
 such, as well as bad data. However, this comment indicates that if the
 exception is raised, it always means it is improperly signed, but it might
 be a low-level database error in reality:

 {{{#!c++
     /// \exception DataSourceError The zone isn't properly signed with
 NSEC3
     /// (NSEC3 parameters cannot be found; no NSEC3s are available, etc).
 }}}

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