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

[David Blacka <davidb@verisignlabs.com>]

On Monday 24 March 2003 10:55 am, Ólafur Guðmundsson wrote:
> <DS document editor>
> 
> I'm not trying to be stubborn about this, but I do not see the
> benefit of the current rules for inclusion of KEY RRset in
> additional section.

I agreed with this.  The current rules do not make sense in light of DS.

> My assertion is that in most common cases there is NO savings,
> see the example below.

My assertion is that there may be savings, and including the KEY RRset does 
no harm (since it can be silently truncated).

> >I am a strong supporter of the policy of including KEY records as
> >early/often as possible. Minimising number of RTT iterations is a major
> >speed hack, in my humble opinion.
> 
> RFC2535 specifies 4 cases where KEY records are to be placed in
> the additional section:  SOA,   NS, A, AAAA
> 
> Do you support the rule for all four or a subset ?

A superset.

> My assertion is that a security aware resolver when it sees a DS on a
> referral (for <zone X>) it SHOULD issue two queries in parallel:[2]
>          one following the tree
>                  QN: <qname>  QT: <qtype> QS: <one of zone X NS>
>          second one asking for the KEY RRset of the zone just discovered.
>                  QN: <zone X> QT: KEY  QS: <one of zone X NS>
> 
> If resolver does this, users will not see any speed difference.
> If the resolver has the KEY set for <zone X> there is no need to ask
> the second question.

Wait a minute.  Parallel queries are a pretty nice client strategy, but it 
isn't particularly optimal for servers.  However, if the standard 
recommends a parallel query strategy, then including the KEY RRset is 
certainly less attractive.
 
> To avoid the second lookup the following rules can help:
>          "referral SHOULD include the covering KEY RRset"
> This is saying that the KEY RRset signing DS or NXT is placed in the
> additional section.
> 
>          "always include covering KEY RRset."
> 
> but this is not what the 2535 rules are saying.

Correct.  The DS document needs to change the 2535 rules.  I am arguing 
that it should be changed to this rather than its opposite.

Always including the covering KEY RRset makes sense to me.  Essentially, 
you include the KEY RRset as soon as there is a signature that would need 
the keys in order to verify.

As a caveat, however, it should be pointed out that without more 
operational experience, it is hard to tell what approach is best.  If a 
significant percentage of DNSSEC responses get the KEY RRset truncated, 
maybe parallel queries are the way to go, and servers should not waste 
their time trying to stuff the KEY RRset into the additional section.  If 
the larger UDP responses more frequently fragment, perhaps parallel 
queries are also ultimately kinder to the network.  Or maybe not.

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