Subject: Re: NSEC+ and NO

From: Ben Laurie <[email-masked]>
Date: Tue, 01 Jun 2004 11:42:18 +0100

Alex Bligh wrote:
> --On 29 May 2004 23:06 +1200 [email-masked] wrote:
> 
>> (a) retains authenticated denial for all but a few highly pathological
>> cases, but appears trivial to defeat.  (b) loses authenticated denial
>> for all non-existent domains, but will reliably prevent zone walking.
> 
> 
> Two questions:
> 
> 1. Is there a situation where lack of authenticated denial can result
>   in returning the wrong data in response to a query (meaning as opposed
>   to returning no data when there isn't one)? - i.e. if NSEC were optional,
>   does one leave oneself open to more than a denial of service attack
>   where non-existence is spoofed? (I am asking here to what extent
>   whether temporarily dropping authenticated denial in those zone operators
>   with problems with enumerability is likely to be a fair price to pay).

For example, returning NXDOMAIN instead of an A or MX record for a 
domain name used for email causes all your email to get dropped instead 
of queued. This strikes me as bad.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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

---

From: Don Stokes <[email-masked]>
Date: Thu, 03 Jun 2004 13:09:04 +1200

>   with problems with enumerability is likely to be a fair price to pay).

Was thinking this one through last night, and yes there is.

The problem is search lists.

If I have a search list of "a.example" and "b.example", and I query
"foo", I will look for:

	foo.a.example.
	foo.b.example.
	foo.

If a.example is a secured zone, I need an authenticated yes or no for
foo.a.example before I can proceed to foo.b.example.  If a.example
exists but doesn't provide authenticated denial, and foo.a.example does
not exist, the search can not proceed when it should.  Failing to
provide the indication required to fall through to foo.b.example in this
case constitutes "wrong data".

If the search were to accept unsecured failure as a fall-through, there
is data for foo.a.example, but somebody is hiding it from me, then I
could erroneously fall through to foo.b.example when foo.a.example did
exist.  That too would constitute "wrong data".

I don't think this affects TLD zones significantly; this could only
affect the TLD if the TLD itself was placed in the search list.  That
could reasonably be described as a configuration error.  Similarly, I
would describe placing a domain that didn't exist into the search list
should be considered a configuration error.  (Note that in my example,
the domains in the search list are assumed to exist.)

IMAO of course.

-- don