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

[Ólafur Guðmundsson <ogud@ogud.com>]

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