Subject: Re: NSEC2 01

From: Ben Laurie <[email-masked]>
Date: Wed, 04 Aug 2004 03:08:43 +0100

Scott Rose wrote:
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]On Behalf Of Samuel Weiler
>>
>>I'm not convinced that the wildcard discussion/example is correct.
>>Perhaps Ed Lewis or Bob Halley can comment?
>>
> 
> 
> The draft authors would be better able to answer, but from my take-
> 
> I'm guessing it's the part about response construction.  In the example, I
> don't know why 2) non-existance of b.c.d.e. is there.  Shouldn't the EXIST
> RR and subsequent NSEC2 RR show who the closest encloser is?  That's how the
> current DNSSECbis spec does it.

Actually not - the canonical ordering subtly demonstrates the 
nonexistence of b.c.d.e at the same time as the nonexistence of 
a.b.c.d.e - suppose the previous record is c.e, then the relevant NSEC 
would look like this:

c.e. NSEC c.d.e.

if c.d.e exists. If it is an ENT, caused by, say, a.c.d.e, then:

c.e. NSEC a.c.d.e.

Both of these show that both a.b.c.d.e and b.c.d.e do not exist, and, in 
fact, you can always show everything needed with just two NSEC records. 
Unfortunately, obfuscation removes this elegance.

 >  The server only needs to provide:
> 
> 1.  proof that the exact name doesn't exist
> 2.  proof that there isn't a wildcard at the closest encloser.  One that
> could have been expanded to provide a postive response.
> 
> In this case, there is a EXIST RR to show the closest encloser.  In some
> cases, that isn't necessary, as there will be RRs at the closest encloser.

The EXIST RR doesn't _prove_ the closest encloser unless you also prove 
there is no closer one.

Cheers,

Ben.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>