RFC 4470 bitmap (Was Re: Authenticated denial of existence...)

As a result of writing down text relating RFC 4470 in
draft-gieben-auth-denial-of-existence-dns, I come to the following
observation:

RFC 4470 sets requirements for the next owner name in the generated NSEC
record. Specifically, the next owner name is lexically before the actual
next existing name in the zone. The next owner name must be lexically
after the QNAME. The span may not cover any existing names.

Main point: I cannot find requirements for the owner name. In other
words, that may be an existing name.

But the RFC explicitly says:

   The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
   bits set and SHOULD NOT have any other bits set.

That is only true if the owner name does not exist. So either this
requirement should be relaxed, or there should be an additional
requirement that the generated NSEC owner name may not exist.

(By the way, I think the requirement should be relaxed, because a
minimally covering NSEC record may also be used in a NODATA response)

Best regards,
  Matthijs


On 11/20/2013 01:12 PM, Tony Finch wrote:
> Ted Lemon <[email protected]> wrote:
> 
>> Is this on anyone's radar?   What are your thoughts about it?
>>
>> https://datatracker.ietf.org/doc/draft-gieben-auth-denial-of-existence-dns/
> 
> A really nice and helpful document.
> 
> A suggestion:
> 
> It should discuss RFC 4470 Minimally Covering NSEC Records, and the
> related idea of NSEC3 "white lies" implemented by Dan Kaminsky's
> Phreebird. (I can't immediately find a good description of how the latter
> works.) Both these require on-demand synthesizing and signing of negative
> responses, whereas the mechanisms that Miek's draft currently covers are
> all designed for serving from a pre-signed zone file without requiring
> online private keys.
> 
> Tony.
> 

_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext