Re: Q-03: inclusion of KEY records in additional records section

[David Blacka <davidb@verisignlabs.com>]

On Wednesday 12 February 2003 02:21 pm, Ólafur Guðmundsson wrote:
> </chair>
> <DS document editor>
> 
> Issue: Is there need to specify that KEY records be placed in additional
> section on certain queries/responses.
> 
> Q: Can the DS document outlaw the rules from 2535 that requires
> inclusion of KEY in additional section ?
...
>     (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same
>     name (perhaps just a zone key) SHOULD be included as additional
>     information if space is available. If not all additional information
>     will fit, type A and AAAA glue RRs have higher priority than KEY
>     RR(s).

Hmm.  I must have initially misread this section.  I more or less 
internalized it as "return the KEYs in the ADDITIONAL section when 
returning SIGs that need to be verified with those keys."  Which, of 
course, isn't what it says at all.  But that is what made sense to me.  
Then, in a world where there was no truncation, a resolver would get back 
all of the info it needed to validate the record in a single round trip.  
This was before DS was introduced, of course.

Given this rule, it looks to me that the only case where one would *not* get 
the zone apex keyset back (barring truncation) is a referral.  NXDOMAIN has 
the zone SOA, postive and NODATA responses have the zone's NS set.  Maybe 
I'm missing something.

> DS document eliminates the NULL-KEY and replaces its role with a rule
> requiring NXT in authority section of referrals.
> 
> Some Justifications for eliminating rule 1:
> a. There is no need to push NULL KEY records anymore
> b. The rule is complex in implementation as KEY is the lowest priority
>     RRset to be included in additional section.
> c. The rule does only partially accomplishes its intent (see example 
below)
> d. The rule makes negative answers much bigger as the SOA in authority 
section
>     triggers the rule.
> e. A security aware resolver should know what information it needs and be 
able
>     to ask for multiple RRsets in parallel.
> f. The information is going to be redundant in many cases.

It seems to me that with DS, this rule should be changed somehow.  We can 
either eliminate it or strengthen it.  By "strengthen", I mean make it 
return the zone KEY rrset in referral cases as well.

Eliminating the rule (never returning KEY rrsets in the additional section) 
optimizes for code complexity and message size at the expense of round 
trips.

Strengthing the rule does the opposite: optimizes for round trips at the 
expense of code complexity and message size.

I'm not sure which is right.  At the moment I would probably vote to 
eliminate the rule.  Smaller messages and more predicable client behavior 
seems better than fewer round trips at the moment.

-- 
David Blacka    <davidb@verisignlabs.com> 
Sr. Engineer    Verisign Applied Research


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