Subject: REOPEN: DNSSECbis-Q-8: non-zone KEY RRs at apex

From: "Scott Rose" <[email-masked]>
Date: Tue, 6 May 2003 15:29:44 -0400

This matter is still open.  Taking Simon Josefsson's comments:

Q:  Should the language in Section 2 of the protocol draft allow non-zone
KEY RRs at a zone's apex?

Discussion:

Section 2 of the protocol draft states:

"Other public keys associated with other DNS operations can be stored
in KEY RRs that are not marked as zone keys. Non-zone key KEY RRs
MUST NOT appear at delegation names. Non-zone key KEY RRs also
SHOULD NOT appear at the zone apex, because large KEY RRsets add
processing time at resolvers. Non-zone key KEY RRs MAY appear at any
other name in the zone. "

However, there is no clear documentation as to where this was updated from
RFC 2535 before.  RFC 3445 (Restrict KEY) only restricts KEY to DNSSEC
protocol uses, but not their location.  This was present in -00 version of
draft and unmentioned until recently on namedroppers.

Should the wording be changed to say that "non-zone KEY RRs MAY appear at a
zone apex"?

NOTE:  This discussion should be restricted to the apex.
Restricting/allowing KEY RRs at delegation points will be the subject of a
different discussion thread.

Scott

--
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: [email-masked] (David C Lawrence)
Date: Tue, 6 May 2003 23:03:34 -0400

> Should the wording be changed to say that "non-zone KEY RRs MAY appear at a

I'm in favour of this change.  Outlawing it is an unnecessary
restriction of extremely little practical benefit.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 May 2003 16:48:31 -0400

>KEY RRs at a zone's apex?

The language in 2.1 should not make any restrictions at all on the 
data being held.  (Ref. Mike St. John's message.)  In addition, I 
find a lot of the wording there to be hard to follow.  So much so I'm 
getting a headache trying to comment on it.

Perhaps we should start by recognizing the kinds of keys.  Zone keys 
have the zone bit set to 1.  All other keys have the zone bit set to 
0.  This isn't why we call them SIG(0) keys, though, but it might as 
well be.  In fact, there is really no such thing as a SIG(0) key - 
there are KEY RR's that hold the public component of a key that 
generated the signature in a SIG RR whose type covered is 0.

So it seems to me that there are zone keys, keys that validate 
sig(0)'s, and useless keys - SIG(0) keys that aren't in use in a 
SIG(0) RR.  I point this out because it is only a bit more precise 
than "other public keys associated with other DNS operations."

I am against requiring that there be a zone key at the apex of a 
signed zone.  (Do we still have the notion of a zone being "signed?") 
It's possible to configure keys in all relevant resolvers.  If 
there's a parent-held DS RR, why can't a resolver see that and feel 
justified in using the configured key that is indicated by the DS RR?

I can't think of a reason to have tailored restrictions on KEY RR 
ownership.  I can think of reasons to restrict how the keys are used 
in the validator.  That's a different story.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Note to pilots: a three-point landing SHOULD NOT include a wing.