BIND 10 #1587: auth::Query NSEC3 support: cleanup

BIND 10 Development do-not-reply at isc.org
Wed Feb 22 07:53:42 UTC 2012


#1587: auth::Query NSEC3 support: cleanup
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120306
  critical                           |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  NSEC3  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:12 kevin_tes]:

 Thanks for the prompt review.

 > Hello,all seems good to me.
 >
 > For one thing I am not sure. In this method:
 > + uint8_t
 > + Query::addClosestEncloserProof(ZoneFinder& finder, const Name& name,
 > +                                bool exact_ok, bool add_closest)
 >
 > For opt-out,should we valid the opt-out flag been set? If not, I do not
 think we need "bool exact_ok" this parameter.

 I'm not sure if I understand the concern, but if you mean whether it's
 okay if we skip checking the NSEC3 optout bit when optout is allowed
 (exact_ok = true) and we get both closest and next NSEC3 (in which
 case the "next" NSEC3 should have the optout bit set), the policy here
 is to basically trust the zone signer, and if it's a broken zone we'll
 let the validator detect the error.  This is documented in the header
 file description.  This policy itself could be discussed if you don't
 like it, but it was derived from the pre-refactoring implementation;
 this branch doesn't change that semantics.  So, if you want to
 continue the discussion I'd suggest doing it separately from this
 ticket (so we can close it sooner).

 As for the changelog, I simply listed the developer in alphabetical
 order, which I think is quite normal in cases like this.  You don't
 have to be too humble:-) but if you really want to reorder them, I'm
 okay with that, too.

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


More information about the bind10-tickets mailing list