Re: new DS draft question

[Brian Wellington <Brian.Wellington@nominum.com>]

On Tue, 5 Mar 2002, Ólafur Guðmundsson wrote:

> At 03:01 PM 3/5/2002, Brian Wellington wrote:
> >The new draft contains the following text:
> >
> >    An authoritative server queried for type DS MUST return the DS RRset
> >    in the answer section along with the corresponding NXT RRset in the
> >    authority section.  If the server is authoritative for both parent
> >    and child zones, the answer MUST be from the parent.  A caching
> >    server MUST behave the same way, returning the DS RRset and the
> >    parent's NXT RRset, if records are available.
> >
> >I don't understand why the NXT record is returned on a successful query.
> >The querying server needs only the DS record and its signatures to
> >continue on the validation process, and including an NXT record in the
> >authority section makes this look confusingly like a negative response.
> >Is there a reason for doing this?
> 
> This was covered on the namedroppers mailing list thread "DS design
> questions" stared on January 2. This was question 3. The people that
> commented on this question (including yourself) all said/implied send
> back both.

Hmm.  I don't remember intending to say that, but looking back, I was not 
all that clear.  I was trying to say that if DS/NXT records are returned, 
they should be in the authority section.  I remember wondering why the NXT 
was needed in a secure referral, but not caring enough to ask.

> The main reason DS is specified this was:
> Provide a paranoid resolver with everything it needs in the first answer.

Seems reasonable for referrals.  I don't think adding the NXT in answers
is useful, though.

> DS can only reside at a delegation, the only way to prove this is a
> delegation is to check the bits in the upper NXT.

I guess this is true, but it seems unimportant.  If the DS validates, it
should be an indication that the name is a delegation.  Otherwise, the
parent zone is confused, and things won't work anyway.  To prove that it's
an insecure delegation involves the NXT, but to prove that it's a secure 
delegation only needs the DS.

> I agree, this is confusing to resolvers (as a matter of fact one resolver that
> I have been playing with takes the upper NXT and uses it to prove that
> the name/type requested does not exist).
> 
> Do we need some rules on when NXT is to be considered negative answer and
> when it is supplied to assist in security proofs ?

Maybe.  Adding NXTs to non-negative answers is already dangerous, and this 
might make non-answer processing even closer to impossible.

> >I also don't fully understand why the NXT needs to be present in referrals
> >to secure zones (the DS is already there, and all that's needed), but
> >that's another story.
> 
> See above about paranoid security aware resolvers.
> The WG needs feedback from resolver writers if this is help- or harmful.
> I personally have no problem changing the ID to reflect what is best
> for the protocol.

This seriously breaks at least one resolver (BIND 9), which treats 
DS-enabled referrals as negative answers.  It's unclear whether this is a 
bug or a case of reasonable behavior that no longer works.

Brian


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