Subject: [dnsext] CDS RRTYPE review - Comments period end Dec 6th

From: [email-masked]
Date: Mon, 15 Nov 2010 18:10:33 -0500

Forwarded on behalf of George Barwood.

--begin 5395 template URI--

   A.    Submission Date: 15 November 2010

   B.    Submission Type:
         [X] New RRTYPE
         [ ] Modification to existing RRTYPE

   C.    Contact Information for submitter:
            Name: George Barwood
            Email Address: [email-masked]
            International telephone number: +44 1452 722670
            Other contact handles: N/A

   D.    Motivation for the new RRTYPE application?

         To allow a copy of the DS RRset [RFC4034] to be published 
         in the child zone, which is used to update the parent DS RRset.
         It is expected that this will allow the rollover of a key signing
         key to be automated.

   E.    Description of the proposed RR type.

         The format is identical to the DS record.
         However there is no special processing for servers/resolvers.        

   F.    What existing RRTYPE or RRTYPEs come closest to filling that
         need and why are they unsatisfactory?

         None.

   G.    What mnemonic is requested for the new RRTYPE (optional)?

         CDS to stand for "Child DS".

   H.    Does the requested RRTYPE make use of any existing IANA
         Registry or require the creation of a new IANA sub-registry in
         DNS Parameters?

         It uses the same registries as the DS record.

   I.    Does the proposal require/expect any changes in DNS
         servers/resolvers that prevent the new type from being
         processed as an unknown RRTYPE (see [RFC3597])?

         No.

   J.    Comments:
         An RFC describing in detail how the CDS RRset may be used
         to update the parent DS RRset is anticipated. The current draft
         is draft-barwood-dnsop-ds-publish-01.

--end 5395 template URI--

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Nov 2010 18:12:40 -0500

Sorry for the noise, all, I fat-fingered the redirect.

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 16 Nov 2010 03:21:40 -0500 (EST)

>         However there is no special processing for servers/resolvers.

I suggest including a citation to RFC3658.

>         need and why are they unsatisfactory?

This analysis is obviously incomplete.  At the very least, explain why 
the three RR types that share the same format (DS, TA, and DLV) are 
unacceptable.

>         It uses the same registries as the DS record.

Name them?  They are "Delegation Signer Resource Record
Digest Algorithms" and "DNS Security (DNSSEC) Algorithm Numbers".

http://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml
http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

-- Sam

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Tue, 16 Nov 2010 10:02:17 -0700

> the three RR types that share the same format (DS, TA, and DLV) are

+1. Especially since the draft contains a section that discusses a new
RR compared to reusing the DNSKEY RR. "A new resource record type is
preferred to using flags in the DNSKEY RRset". This must be better
explained for me to support this draft.

/Stephan

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Nov 2010 12:19:29 -0500

> explained for me to support this draft.

Note that this thread is not actually discussing the _draft_, just the
RRTYPE assignment request.  Also, note that we don't actually have the
assignment type machinery up and running yet.  In particular, IANA
hasn't appointed an expert who will actually do this evaluation.
Nevertheless, I'm sure the chosen expert will take into consideration
discussion of the assignment request in this thread.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Chris Thompson <[email-masked]>
Date: 16 Nov 2010 23:42:27 +0000

>the three RR types that share the same format (DS, TA, and DLV) are 

Well, obviously not DLV, to start with. A DLV record at the apex of a
zone is a purported trust anchor for the root zone, nothing to do with
the zone in which it occurs.

-- 
Chris Thompson
Email: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Nov 2010 19:40:46 +1100

In message <[email-masked]>, Chris Tho
> the zone in which it occurs.

No.  For example we could split the namespace under dlv.isc.org
into multiple zones (and would have done if we need to for scaling
reasons).  Only a DLV at dlv.isc.org would represent the root. DLV
records at the apex of any other zones would represent the zone
with the dlv.isc.org suffix removed.

DLV only has special meaning within zones which are being used for
dnssec look-aside valiation.  This is the same as PTR has special
meaning within in-addr.arpa and ip6.arpa but not outside of those
zones.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 17 Nov 2010 04:13:15 -0500 (EST)

On Tue, 16 Nov 2010, Chris Thompson wrote:

>> This analysis is obviously incomplete.  At the very least, explain why the 
>> three RR types that share the same format (DS, TA, and DLV) are 
>> unacceptable.
>
> Well, obviously not DLV, to start with. A DLV record at the apex of 
> a zone is a purported trust anchor for the root zone, nothing to do 
> with the zone in which it occurs.

So what?  One choice of semantics for a record need not preclude other 
choices: see the TXT record.  :-)  Seeing a DLV RR should not trigger 
any special processing.  Unless validators have configured a domain as 
a DLV domain, having a DLV RR in that domain should be a non-issue.

That doesn't mean reusing the RR type is a good idea, just that this 
arugment against it is bunk.

As a further nit: the described semantics (DLV RR at zone apex = root 
trust anchor) are not correct.  A DLV domain (v. zone) need not be a 
separate zone, and it may include delegations (sub-zones). 
Furthermore, the top level of a DLV domain may not target the root. 
A DLV domain can target any zone (e.g. .net), not just the root.  See 
section three of RFC5074.  BIND makes the assumption that the top 
level of every DLV domain targets the root, but that it an 
implementation quirk that can worked around in practice.

-- Sam