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