BIND 10 #1177: NSEC support in new data source

[BIND 10 Development]

#1177: NSEC support in new data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110927
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:8 jinmei]:

 One quick point I clearly need to correct (myself):

 > > - Is this a question of what's the expected proof of empty
 > >   non-terminal wildcard match?
 > >   [...]
 > >   If so, I'm not 100% sure either, but I guess it's basically no
 > >   different from other empty non-terminal case.  That is, with having
 > >   wild.*.foo.example.org, the negative proof for a.foo.example.org
 > >   would be "prev_name(wild.*.foo.example.org) NSEC
 wild.*.foo.example.org..."
 > >   I'd also suggest you check this behavior with other implementation.
 > >   (Note, however, that you'll need "check-names master ignore;" for
 > >   BIND 9 to force it to accept empty wilds)
 >
 > After an hour of fighting bind9, I didn't manage to make it return
 signatures and NSEC data, so I gave up and implemented it this way. I seem
 to be a bad admin :-|.

 After playing with existing implementations and re-reading RFC4035, I
 realized I had been a bit confused when I made this comment.  Using
 the above example, this should be the case for Section 3.1.3.2 of
 RFC4035.  And,
 {{{
    o  An NSEC RR proving that there is no exact match for <SNAME,
       SCLASS>.
 }}}
 should be:

 {{{
 prev_name(a.foo.example.org.) NSEC next_name(a.foo.example.org.) ...
 }}}
 while
 {{{
    o  An NSEC RR proving that the zone contains no RRsets that would
       match <SNAME, SCLASS> via wildcard name expansion.
 }}}
 should be
 {{{
 prev_name(*.foo.example.org) NSEC wild.*.foo.example.org. ...
 }}}

 And, in my understanding of the current branch, the latter is out of
 scope (deferred to #1244), right?  So, in the context of this branch
 what should be returned is the former.  Note that
 prev_name(a.foo.example.org.) may not be equal to
 wild.*.foo.example.org.  If there's an RR for 1.foo.example.org, for
 example, that will be the previous name.

 So, commit dd340b3 is not really (yet) correct, and should be revised.

 As for experiments with other implementations, try the attached zone
 file for zone "jinmei.org".  For BIND 9, you'll need to specify
 check-names in the options section:
 {{{
 options {
 ...
         check-names master ignore;
 };
 zone "jinmei.org" {
 ...
      file "jinmei.zone.signed";
 };
 }}}

 and query for c.b.jinmei.org and ham.b.jinmei.org.  Actually, BIND 9
 doesn't seem to return a correct answer.  I also tried it with NSD
 3.2.7, which seems to provide the really expected behavior.

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