Roy Badami wrote:
> Ben> No, because there should be no records below the NS record in
> Ben> the parent zone, so if there is an NS, it will be at the
> Ben> closest encloser. The same argument applies to NSEC, as far
> Ben> as I can see.
>
> Indeed there shouldn't. So presenting an NSEC record that proves that
> such a name exists proves that the delegation doesn't. DNSSECbis
> non-existence proofs implicitly rely on this.
>
> When I query for a.b.c.d.e and get the response:
>
> _.b.c.d.e. NSEC aa.b.c.d.e. A
>
> this implicitly proves to me that no delegation exists between the
> name I queried for and the zone apex, because if it did then the NSEC
> owner name and target name wouldn't be in-zone.
>
> When I query for a.c.d.e.e and get the response:
>
> b.c.d.e. NSEC aa.b.c.d.e. A
>
> this explicitly proves to me that b.c.d.e is not a delegations point
> (no NS record) and implictly proves that there is no delegation
> between b.c.d.e and the zone apex, for the same reason.
>
> So with DNSSECbis the set of NSEC records you construct to prove that
> there is no relevent wildcard that could have matched also happen to
> prove that there is no delegation for which you should have received a
> referal.
>
> Since the NSEC3 records are ordered by hash, not original owner name
> (I think) it seems to me that you don't get this proof for free, and
> have to explictly provide covering NSEC3 records for all the places a
> delegation could have existed, to prove that it doesn't.
>
> But I haven't thought about this deeply, and could be mistaken...


I believe that since NSEC3 also shows the record at the closest
encloser, the same check works.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: