Subject: Re: NSEC+ and NO

From: Don Stokes <[email-masked]>
Date: Wed, 02 Jun 2004 15:25:16 +1200

Ben Laurie <[email-masked]> wrote:
>Alex Bligh wrote:
>> 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).

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. 

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

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

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