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

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

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

Can some resolver writers please speak up on this issue?

At 16:44 2003-03-20, Måns Nilsson wrote:

--On Wednesday, March 19, 2003 23:45:05 -0500 David Blacka
<davidb@verisignlabs.com> wrote:

> I've changed my mind.  I now think that servers SHOULD attempt to send
> the  KEY RRs in the additional section.  That is, I think that we should
> strengthen the rule rather than eliminate it.  My reasoning is that:
>
>   * the code complexity of doing this is pretty minor,

Agreed on the server side. On the resolver side there is no difference
as the resolver MUST be able to look up any missing information.


>   * optimizing for fewer round trips makes sense: bandwidth will increase
> over time, but we cannot exceed the speed of light,

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


>   * since the client (via EDNS0) controls the max size of the response
> and  the key RRs can be silently truncated, the extra size of the message
> should  do no harm.

I agree 100%.


This was also the conclusion arrived at during smalltalk during the
pre-IETF DNSSEC workshop.

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 ?

Given the example below, where is the benefit?



Trace (QN: query name, QT: query type, QS: server queried)
R: QN: a.b.c.d.example. QT: TXT   QS: 1
S1:
   AU: d.example.   NS  2
       d.example.   DS
       d.example.   SIG(DS)

R: QN: a.b.c.d.example. QT: TXT  QS: 2
S2:
   AU: c.d.example. NS 3
       c.d.example. DS
        c.d.example. SIG(DS)

R: QN: a.b.c.d.example.   QT: TXT  QS:3
S3:
   AU: b.c.d.example. NS 4
       b.c.d.example. DS
        b.c.d.example. SIG(DS)

R: QN: a.b.c.d.example.   QT: TXT  QS:4
S4:
   AN: a.b.c.d.example.   TXT
       a.b.c.d.example.   SIG(TXT)

In order to validate the chain the resolver still needs to query for
KEY's for example., d.example., c.d.example., b.c.d.example.

Just to be fair, cases where there is benefit:
- negative answers, the SOA rule saves one query[1].
- when same server has child and a ancestor, during backtracking to
the known KEY RRset, NS rule will save query KEY RRset, but DS sets have
to be explicitly looked up.
- Priming query for root, NS and KEY sets arrive in one packet
(if the signed KEY set is small enough to fit with the
signed NS set and glue).

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.

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.

Olafur

[1]. In the case of negative answers resolver will frequently have
learned the KEY previously. What the percentage is unknown (at least
to me).

[2] One of the discussions the comes up when people are writing DNSSEC
resolver is optimize for network or crypto delay?
The argument is if you optimize for network then you may perform unneeded crypto, the second case all crypto validation takes place when it is
known that there DS +KEY chain to the answer.
There is no one right answer.


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