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: Wed, 02 Jun 2004 15:25:16 +1200

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

Secure delegation doesn't work securely without NSEC, as referral NS
records are not signed.  Any man in the middle can respond with an
unauthenticated NS RRset, and if you're expecting a signed response, you
have to have either a signed DS record or a signed NSEC record before
you can follow the delegation.  Otherwise you might be following a
forged referral.

Thus, authenticated denial is required for secure delegation.  One
should always return an NSEC record in any case where one would return
NODATA in standard DNS.  

A completely different question is whether one can get away with not
returning NSEC where standard DNS would return NXDOMAIN, and I think
that's the question that Alex is asking. 

>of queued. This strikes me as bad.

If we're only talking about lacking authenticated denial for records
that do not exist, i.e. cases where you'd get NXDOMAIN rather than
NODATA, then we're not talking about returning NXDOMAIN instead of A or
MX.  

Getting an NSEC record tells me that a domain definitely doesn't exist
(and I can bounce email to it, or whatever).  If I don't get either
signed data or an NSEC, I don't know for sure, and I have to retry; so
you're talking about mail (that isn't going to be delivered anyway)
getting re-queued instead of bounced.

That might be a problem for some; certainly I've frequently mis-typed an
email address and not been informed of the message's non-delivery until
much later.  I can imagine mail queues filling with undelivered spam
because a DNSSECbis speaking mail server can't get a definitive yay or
nay out of the DNS though.  

-- don

---

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