Re: [DNSOP] The DNSOP WG has placed draft-ogud-dnsop-maintain-ds in state "Candidate for WG Adoption"

Olafur Gudmundsson <> Sun, 08 November 2015 16:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9A9AE1A1EFC for <>; Sun, 8 Nov 2015 08:49:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fIOUCFF_PWS1 for <>; Sun, 8 Nov 2015 08:49:22 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 51CA31A1EEE for <>; Sun, 8 Nov 2015 08:49:22 -0800 (PST)
Received: from (localhost.localdomain []) by (SMTP Server) with ESMTP id A366A38021E; Sun, 8 Nov 2015 11:49:21 -0500 (EST)
Received: by (Authenticated sender: with ESMTPSA id 23C553801FA; Sun, 8 Nov 2015 11:49:20 -0500 (EST)
Received: from [] ([UNAVAILABLE]. []) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by (trex/5.5.4); Sun, 08 Nov 2015 11:49:21 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Olafur Gudmundsson <>
In-Reply-To: <>
Date: Sun, 08 Nov 2015 11:49:19 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Shane Kerr <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Subject: Re: [DNSOP] The DNSOP WG has placed draft-ogud-dnsop-maintain-ds in state "Candidate for WG Adoption"
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 08 Nov 2015 16:49:25 -0000

> On Nov 5, 2015, at 9:55 PM, Shane Kerr <> wrote:
> Dear dnsop working group,
> On Thu, 05 Nov 2015 17:20:18 -0800
> IETF Secretariat <> wrote:
>> The DNSOP WG has placed draft-ogud-dnsop-maintain-ds in state 
>> Candidate for WG Adoption (entered by Tim Wicinski)
>> The document is available at
> First, I definitely think that this should be a working group document.
> Second, some comments about the draft (with the hope that it does get
> adopted):
> * I think "all 0" CDS/CDNSKEY indicating desire for deletion is fine.
>  Defining a DNSKEY algorithm that does not actually define a DNSKEY
>  algorithm is a bit weird.
> * Perhaps a paragraph clarifying behavior when there is the "all 0"
>  CDS/CDNSKEY AND another CDS/CDNSKEY record is a good idea?
>  Something like:
>    If any other CDS/CDNSKEY record is present in a zone, then the
>    CDS/CDNSKEY records indicating deletion MUST be ignored.   

good suggestion we will adopt it, maybe with some rewording. 

> * The acceptance criteria for new CDS records seem less like a protocol
>  definition and more like an exploration of possible approaches.
>  Probably this is because that is what they are? :P Does it make sense
>  to define more detail? I kind of think "yes", but since there is no
>  deployment experience it's likely that it would all be incorrect.

You are right it is a protocol exploration as we have nothing but what has shown to be difficult to deploy. 
And hopefully you are also wrong on if this advise will be ignored, I hope it will become the bases
of many operations. 

> * I don't see much motivation for "Acceptance policy via authenticated
>  channel". It seems like if you have access to such a channel you may
>  as well just provide the DS record? Or is the idea that you make it so
>  that the administrator for a zone doesn't need to cut/paste DS
>  information but can just check a "delegate this" box?

Well the idea is a that a DNS operator can Identify the request that the CDS/CDNSKEY processing by parent is started. 
possibly even handing over the expected records. 
In my employers case the acceptance policy is we give the people that are willing to work with us the list of keys we will sign with, 
because that is a short list. 

> * Perhaps "Accept with challenge" should provide some advice on how
>  this works. For example, a TXT record with a unique key for each zone
>  (or customer) seems like a good recommendation. It might also make
>  sense if each child domain (or customer) has a unique ownername to
>  look for, to prevent 3rd parties from detecting such bootstrapping.
>  (Yes a 3rd party can see the CDS update followed by the DS update,
>  but they won't know the verification used.) Also to note that after
>  the trust is established that the challenge record should no longer
>  be necessary and can be removed.

There are many different ways to do this
a) generate a random name with a  <type>  record with defined content 
b) put a <type> record at a fixed name with random content 
c) require resigning the CDS/CDNSKEY record with defined expiration time 
etc. it is just a question of imagination what people come up with. 
If the working group wants to recommend one standard way, that is fine. 
Text welcome 

> Sayōnara!
> —
> Shane