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 with
the word 'unsubscribe' in a single line as the message text body.