[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Edward Lewis <lewis@tislabs.com>
Cc: dnssec@cafax.se
From: Simon Josefsson <jas@extundo.com>
Date: Tue, 07 Aug 2001 12:31:24 +0100
Delivery-Date: Wed Aug 8 20:16:41 2001
In-Reply-To: <v03130309b721a0036996@[199.171.39.4]> (Edward Lewis's messageof "Fri, 11 May 2001 09:58:00 -0400")
Sender: owner-dnssec@cafax.se
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.104
Subject: Re: Alpha draft of SEC RR

Sorry for not having cought up on this before, but I have two comments
on the SEC RR idea now.

Edward Lewis <lewis@tislabs.com> writes:

> 3.0 Default values
>
> In the abscence of an SEC RR, a resolver is to assume version 0, using
> the NXT RR.

One must be extremely careful when designing a protocol that is able
to negotiate its security parameters, just look at the complexity of
TLS.

To be in the situation where you know that a SEC RR is absent, there
must have been a previous exchange of NXT or NO records.  This feels a
little bit recursive...

> One of the road blocks to the adoption of NO is the inability to
> inform a resolver that authenticated denial provided by NO rather than
> NXT.  The SEC RR is defined to remove this roadblock, and road blocks
> to other DNS Security improvements.

...but maybe the recursive situation isn't necessary.  I don't see why
the SEC RR is needed by the resolver to determine if NXT or NO is
used.  I didn't see anything in the draft that explains that either.
I think a resolver shouldn't need to know that.  A resolver asks for
the RR it wants to know, and hopefully it receive some kind of answer.
Whether the response should be trusted or not should be determined by
the response, and whatever locally configured policy and keys are
available.  I think you can have four interesting cases:

1) The response includes an answer.  The resolver is happy.  If it
   supports SIGs it may know that the answer was correct (if these
   were indeed included and verified correctly).

4) The response is NXDOMAIN.  The resolver is happy, but without
   NXT/NO it doesn't know anything securely.

2) The response is NXDOMAIN and include NXTs to prove that.  The
   resolver is happy, it knows there wasn't an answer.  If it supports
   NXT it also knows there wasn't an answer _securely_.

3) The response is NXDOMAIN and include NOs to prove that.  The
   resolver is happy, it knows there wasn't an answer.  If it supports
   NO it also knows there wasn't an answer _securely_

Or is there some other cases when a resolver must know aprio whether a
zone uses NXT or NO?


Home | Date list | Subject list