> As promised (though a little late) here are my quirks from the dallas-ietf
> presentation on DNSSEC-bis omissions:
>
> One rant on DNSSEC-bis is that it groups empty-non-terminal response types
> as "name errors" instead of "no data errors" (section 3.1.3.2 of RFC
> 4035). I think it was Rob Austein who explained during the WG session that
> the term "Name Error" used in DNSSEC-bis does not necessarily reflect
> "rcode=3 (name error)". In hindsight, this is purism, and does not create
> any holes in the validation logic. This is not all that important, so my
> suggestion here is to remove the following part in dnssec-bis-updates:
>
> 2.2. Empty Non-Terminal Proofs
>
> To be written, based on Roy Arends' May 11th message to namedroppers.
>
> The editors are trying to figure out whether what's really required
> here is a discussion of the relationship between DNS RCODEs and
> DNSSECbis.
>


A NSEC record prove that there at no names, with records,
between the owner of the NSEC record and the Next Domain
Name in the zone which owns the NSEC record.

This is not the same as there are no names in the covering
span.

You can determine which empty names exist in the covering
range of the NSEC by taking the NSEC's closest encloser and
the Next Domain Name. If the Next Domain Name is not the
closest encloser and call that E. Strip the left hand label
from E and if that is not the closest encloser you have
found a empty name that exists in the span. If that name
end in a wildcard label you have found a empty wild card
label. Keep striping labels from E until you encounter the
closest encloser to find all the empty names that exist in
the range.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org

--
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: