Subject: Re: draft-ietf-dnsext-dnssec-protocol-06.txt section 2.1

From: Olaf Kolkman <[email-masked]>
Date: Thu, 17 Jun 2004 13:14:13 +0200

Hi Simon,

 * Right now, yes.  But why prevent a possible future use of it?  Unless
 * there is a good reason, that is.  And if there is a good reason, I
 * believe the reason should be stated, to explain the protocol
 * requirement.
 
To prevent long academic discussion it would be nice if you would propose
text that can be cut-n-paste into the documents.

People can than state if they consent or not consent with the proposed text.

--Olaf
  (trying to speed things up)

--
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: Simon Josefsson <[email-masked]>
Date: Thu, 17 Jun 2004 13:52:44 +0200

> People can than state if they consent or not consent with the proposed text.

Hello.  I suggest to remove this sentence:

    DNSKEY RRs MUST NOT appear at delegation points.

In section 2.1.  Doing so would imply that any DNSKEY RRs at
delegation points are treated the same as any other DNSKEY at
unexpected locations: they are ignored.

If people believe the requirement serve a useful purpose, I think the
reason should be stated.

In general, a DNSKEY placed at a location not expected by resolvers is
ignored.  The resolver will never try to get such DNSKEYs, and if it
somehow receive them, it will not use it for validation, because using
them isn't part of the validation algorithm in DNSSECbis.  Why is it
important to treat DNSKEYs at delegation points differently?

With the current text, it appears as if resolvers faced with a DNSKEY
at the delegation point can regard the entire parent zone as bogus,
since it contain RRs which violate protocol requirements.  Resolvers
could also ignore the DNSKEY RR.  But the latter is what I propose the
specification should do, as well.

Thanks,
Simon

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 17 Jun 2004 07:57:29 -0400

For reference, KEY RRs (back before TCR) was discussed as a formal DNSSECbis
question (Q11):

http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01143.html

Something might be able to be pulled out of the thread.

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Olaf Kolkman
> Sent: Thursday, June 17, 2004 7:14 AM
> To: Simon Josefsson
> Cc: [email-masked]
> Subject: Re: draft-ietf-dnsext-dnssec-protocol-06.txt section 2.1
>
>
>
> Hi Simon,
>

---

From: Roy Arends <[email-masked]>
Date: Thu, 17 Jun 2004 14:05:45 +0200 (CEST)

> specification should do, as well.

I totally agree with Simon,

There is nothing special in DNSKEY, nor is there in TXT or INFO records.
All are prohibited at delegation points, and ignored by resolvers.

Roy

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 17 Jun 2004 16:40:20 +0200

FYI, that issue, and the related Q8, was closed in

http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01474.html

With the motivation:

 Q8 - Should the apex allow zone KEY RRs only?
 *CLOSED:  Consensus seems to be no restrictions at all on KEY RR placement
 in a zone *  besides, DNSKEY are the zone keys now.
...
 Q11 - KEY RRs at delegation point.
 CLOSED:  DNSKEY/KEY would be glue.  Not a DNSSEC issue about what to allow
 as non-auth glue.  Local policy about serving and accepting unsigned data
 would dictate.

I'm arguing for the same resolution now.

Regards,
Simon