Subject: Re: new DS draft question

From: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 05 Mar 2002 22:32:11 -0500

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.

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

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

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

         Olafur

--
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: Brian Wellington <[email-masked]>
Date: Wed, 6 Mar 2002 18:24:22 -0800 (PST)

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

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

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

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

> 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 personally have no problem changing the ID to reflect what is best

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

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Fri, 08 Mar 2002 11:40:26 -0500

>delegation only needs the DS.

Correct.

>might make non-answer processing even closer to impossible.

After looking through RFC2535 (and RFC2065) there is nothing said that server
[MAY, SHOULD, MUST] NOT put NXT in positive answer so it was only a question of
time before someone did this :-).

Q1: Is there any practical use for NXT in any positive answer ?

Possible Answer: For any signed data there is no need for resolver to check NXT
unless signature FAILS crypto check, thus NXT should never be sent with 
positive
answer where the data in answer section is signed.
This leaves the case of referral as the NS at delegation is unsigned,
the presence of the NS bit in the NXT and the absence of the SOA bit
proves there is a delegation at this name.
(given how hard it can be for resolvers to get the parent NXT).

Q: Is there need to formalize that NXT MUST/SHOULD NOT be returned when
there are signed records in the answer or authority section?

Q2: Does this affect Opt-in ? > >I also don't fully understand why the NXT 
needs to be present in referrals

>bug or a case of reasonable behavior that no longer works.

DS breaks it already, so what is little bit more of breakage :-)
But this behavior is a bug, if the resolver deducts from the
upper NXT that no answer is possible.
All resolvers must be able to determine if the NXT is material and
relevant, and ignore NXT records that are not.

         Olafur

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 8 Mar 2002 09:52:54 -0800 (PST)

[ post by non-subscriber ]

> Q1: Is there any practical use for NXT in any positive answer ?

There is not only a use, but a requirement.  RFC2535 section 5.3 says
that wildcard expansions (which are positive answers) MUST have NXTs:

5.3 Additional Complexity Due to Wildcards
   [...]
   Furthermore, if a wildcard expansion is returned in a response, in
   general one or more NXTs needs to also be returned in the authority
   section to prove that no more specific name (including possibly more
   specific wildcards in the zone) existed on which the response should
   have been based.

-- 
Andreas Gustafsson, [email-masked]