Subject: Re: DNSSECbis Q-11: KEY RRs at delegation points

From: Paul Vixie <[email-masked]>
Date: Thu, 29 May 2003 05:28:58 +0000

> This was a sidebar topic in Q-8:  non-zone KEY RRs at the apex.
> 
> Q:  Should KEY RRs (any) be allowed at delegation points?

no.

> Discussion:
> There isn't a formal rule already in the documents prior to the DNSSECbis
> re-write.  The KEY@parent idea stated that the delegating zone key would
> appear at a delegating parent in order to set up the chain of
> authentication.
> 
> Now with the DS RR, the zone KEY remains in the delegated child zone.  In
> the latest version of the protocol draft (-01), this is further restricted
> by saying that KEY RRs MUST NOT appear at delegation points.  The topic is
> whether this restriction is necessary.
> 
> If the KEY RR is to be considered glue RRs like the other RRs at the
> delegation point, then it is not signed, and cannot be validated when
> received with the delegation.  Unless it is to be considered authoritative
> for the delegating zone, like the DS RR.
> 
> However, there is no harm to the protocol by allowing it, is there?

yes.  in addition to ed lewis's fine comments, the rule (made implicitly
in 1034 and explicitly in 2181) is that everything at or below a
delegation point is authoritative only in the child.  this means NS and
A RRs held in a parent zone that are at (NS) or at or below (A) the
delegation point, are just hints.  if the parent is queried for them,
the result should be a delegation to the child.

therefore anything present in the parent zone which is at or below a
delegation point is only to be used for delegation responses.

since a KEY RR is not used in delegation responses in a the DS world we
are moving to, it should be an error to specify one at or below a 
delegation point in a parent zone.

--
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: Paul Vixie <[email-masked]>
Date: Fri, 30 May 2003 15:40:13 +0000

> I have no (further) comments on the draft.  I think it should be progressed
> as a PS doc, since it does change the spec (arbeit minor).
> 
> Scott

i am hoping that it will be rolled into the DNSSECbis docs and not become
the first post-revolution change.  imagine how nice it would be if, for one
shining instant, a single unified document series described the whole of
dnssec.

re:

> ----- Original Message ----- 
> From: "Randy Bush" <[email-masked]>
> To: "namedroppers" <[email-masked]>
> Sent: Thursday, May 29, 2003 3:17 PM
> Subject: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt
> 
> 
> > this initiates a two week wg last call on
> >
> >     draft-ietf-dnsext-dnssec-2535typecode-change-01.txt
> >
> > and, should it be info or ps?  i suspect the latter as it modifies
> > a ps document, but i could be wrong.
> >
> > randy
> >
> >
> > --