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

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 12 Feb 2003 14:21:09 -0500

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

Background:

RFC2535 Section 3.5 says:
    An explicit request for KEY RRs does not cause any special additional
    information processing except, of course, for the corresponding SIG
    RR from a security aware server (see Section 4.2).

    Security aware DNS servers include KEY RRs as additional information
    in responses, where a KEY is available, in the following cases:

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

    (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same
    name (usually just a host RR and NOT the zone key (which usually
    would have a different name)) SHOULD be included if space is
    available.  On inclusion of A or AAAA RRs as additional information,
    the KEY RRset with the same name should also be included but with
    lower priority than the A or AAAA RRs

Rule 2 is obviously there for optimization reasons and was put there
to push out application (IPSEC) keys. As applications are now directed
to get their own key RR type and NOT place any additional section
processing requirements on DNS, the value of this rule is
operationally minimal.

The first rule is more interesting and is focused at the needs of
DNS protocol elements. There are two reasons for this rule,
1. Optimization: attempt to distribute KEY RRsets with fewer round trips.
2. NULL KEY push: RFC2535 has NULL-KEY residing in the parent zone for
    unsecured delegations. The rule above forces the push of this KEY set
    along with the NS set in referrals.

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.

Example showing why the optimization does not work in a common case.
This is an example in secure universe.
Q: a.b.c.d.example.   TXT   (all zones are one label deep).
Server 1: is authoritative for example.
Server 2: is authoritative for d.example.
Server 3: is authoritative for c.d.example.
Server 4: is authoritative for b.c.d.example.

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.

	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: David Blacka <[email-masked]>
Date: Wed, 12 Feb 2003 19:39:48 -0500

> inclusion of KEY in additional section ?
...
>     will fit, type A and AAAA glue RRs have higher priority than KEY

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.

> 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    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 20 Feb 2003 10:36:15 -0500

>inclusion of KEY in additional section ?

Does anyone care if I specify in the DS document that KEY RR SHOULD NOT
be placed in additional section ?

This will simplify DNSSEC implementations, reduce packet sizes and
avoid repeated redundant information.

         Olafur