Subject: Re: [DNSOP] CDS and/or CDNSKEY

From: Warren Kumari <[email-masked]>
Date: Wed, 2 Oct 2013 17:33:40 -0400

On Sep 27, 2013, at 1:53 AM, Matthijs Mekking <[email-masked]> wrote:

> Hi Warren,
> 
> On 09/27/2013 04:27 AM, Warren Kumari wrote:
>> 
>> On Sep 26, 2013, at 12:05 AM, Matthijs Mekking
>> <[email-masked]> wrote:
>> 
>>> Hi,
>>> 
>>> I thought it would be good to start a thread about CDS or CDNSKEY,
>>> given the recent discussion on dnssec-deployment.
>> 
>> Thank you!
>> 
>> I'm off at another meeting and that thread got away from me… :-)
>> 
>>> 
>>> CDS is a nice proposal for automating the the delegation signer 
>>> information at the parent and is able to deal with all possible
>>> rollover scenarios.
>> 
>> Yup.
>> 
>>> It's drawback however is that it cannot be used by registries that
>>> require the delegation signer information to submitted as DNSKEY.
>>> 
>>> There are two straight-forward solutions for this, imo:
>>> 
>>> 1. New RRtype: CDNSKEY Which is similar to CDS except it publishes
>>> the DNSKEY RDATA elements of the to be DS RRset. A parental agent
>>> that calculates the DS itself would poll for the CDNSKEY RRset.
>>> 
>>> 2. Adjust the CDS RR format The CDS RDATA is equal to the DNSKEY
>>> RDATA plus one RDATA element for what (preferred) hash is to be
>>> used.
>>> 
>>> The first solution has some minor drawbacks: * It requires a new
>>> RRtype for something that can also be done within an existing
>>> RRtype (CDS after changing the format). * For the child signer
>>> system it would need an additional configuration knob to decide
>>> whether to publish CDS or CDNSKEY.
>>> 
>>> Adjusting the CDS RR format makes the CDS proposal compliant with
>>> both 'requiring DS' and 'requiring DNSKEY' registries.
>> 
>> 
>> Yup, but the way you have written option 2 (unless I misunderstand)
>> does't allow for "standby keys" .
> 
> It does allow for standby keys. It allows for anything that the current
> specification of CDS allows for (plus more!).
> 
> Basically, option 2 is just like the current CDS proposal, but publishes
> the information unhashed. The additional RDATA element, call it selector
> if you like, informs about how to hash the record.
> 
> So if you want a standby key, publish a CDS record for that key, but not
> its DNSKEY record.
> 

Hi all.

Anyway, we have finally rev'ed the CDS draft, and have (I think) arrived at a compromise that will be acceptable to both views (DS vs DNSKEY).

The 50'000ft[0] view is that the record is now a selector and a data part.
If the selector is 0, the data is a DS record.
It if is not 0, the data is a DNSKEY, and the parent should calculate the DS from that.
(This is largely based upon ideas like that described above. )

This allows children to present DS to those parents who want DS, and DNSKEY to those who would prefer to calculate DS on their children's behalf.

There has been another thread on the whole CDS and CSYNC thing on the DNSSEC-Deployment list (which I'm assuming most folk here have been following as well).

We (the authors or CDS and CSYNC) have had a number of discussions comparing the various pros and cons of draft-kumari-ogud-dnsop-cds (CDS) and draft-hardaker-dnsop-csync (CSYNC). As we we discussed at the DNSOP session in Berlin, we believe that there are *complementary* but *different* solutions.

CSYNC is designed for transferring various delegation information, such as NS, A/AAA glue, etc. It does this by publishing a Type Bit Map of the records that the parent may copy. This means that it copies exactly what is in the child for those types. This makes it unsuitable for DS records, where a child may want to publish DS records for stand-by keys, where they may want to pre-publish a DS records prior to performing key roll, etc. 

CDS (now CTA) is designed specifically for transferring DNSSEC key information from the child to the parent. The child publishes a CTA record containing what they want to parent to publish, and the parent copies this (potentially after computing DS from DNSKEY. This allows for publishing DS records that are not actively in use. CTA *only* handles DS / DNSKEY records, and so does't support the more general solution that CSYNC does -- it is however designed for simplicity.

We have had numerous discussions regarding having a bit in CSYNC that indicates that the parent should look for an updated CTA record. We have come to the conclusion that this is not really worth the bother -- it potentially saves a single poll of the child (if the parent supports both CSYNC and CTA it would have to check for bot) at the expense of additional complexity, corner cases, etc.

So, in summary, we believe that CSYNC and CTA are related, complementary solutions, but solving different use cases. We do not think that coupling them together (nor trying to explain them both in a singe draft) will be helpful.

W

-------------------------
A new version of I-D, draft-kumari-ogud-dnsop-cds-04.txt
has been successfully submitted by Warren Kumari and posted to the
IETF repository.

Filename:	 draft-kumari-ogud-dnsop-cds
Revision:	 04
Title:		 Automating DNSSEC delegation trust maintenance
Creation date:	 2013-10-02
Group:		 Individual Submission
Number of pages: 17
URL:             http://www.ietf.org/internet-drafts/draft-kumari-ogud-dnsop-cds-04.txt
Status:          http://datatracker.ietf.org/doc/draft-kumari-ogud-dnsop-cds
Htmlized:        http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-kumari-ogud-dnsop-cds-04

Abstract:
  This document describes a method to allow DNS operators to more
  easily update DNSSEC Key Signing Keys using DNS as communication
  channel.  This document does not address the initial configuration of
  trust anchors for a domain.  The technique described is aimed at
  delegations in which it is currently hard to move information from
  the child to parent.

---------------------

W

[0]: or 15240m for those folk who use less entertaining units of measurement

> 
>> An option that was discussed (sorry, cannot remember if it was onlist
>> or over a beer) was to have the CDS record be:
>> 
>> RRTYPE <selector> <data>
>> 
>> If the selector is 0, then the data element is a DS record. If the
>> selector is $something_else then the data is a a DNSKEY. The selector
>> could be the hash type that you would like...
> 
> This sounds a lot like option 2 here, only this has different RDATA
> formats depending on the value of one RDATA element.
> 
> 
>> AFAIR, the main objections to this was that it makes parsing
>> *slightly* harder / there is a view that it is less elegant.
> 
> Yes. I would prefer resource records with a static RDATA format.
> 
> 
>> So, I *think* basically what you suggested as option 2, but if the
>> "what (preferred) hash is to be used" part is e.g 0, then the data
>> bit is already hashed.
> 
> What I suggested is always publish a CDS with unhashed information (e.g.
> DNSKEY RDATA) + a selector RDATA element on which hash to be used. If
> the selector is 0, it is up to the parental agent.
> 
> Best regards,
>  Matthijs
> 
>> 
>> Thoughts? W
>> 
>>> 
>>> 
>>> Best regards, Matthijs
>>> 
>>> 
>>> _______________________________________________ DNSOP mailing list 
>>> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>>> 
>> 
>> -- Do not meddle in the affairs of dragons, for you are crunchy and
>> taste good with ketchup.
>> 
>> 
>> 
>> 
> 

--
"Real children don't go hoppity-skip unless they are on drugs."

    -- Susan, the ultimate sensible governess (Terry Pratchett, Hogfather)

---

From: Paul Wouters <[email-masked]>
Date: Wed, 2 Oct 2013 22:24:09 -0400 (EDT)

> This allows children to present DS to those parents who want DS, and DNSKEY to those who would prefer to calculate DS on their children's behalf.

I still strongly prefer CDS (and CDNSKEY) to keep the record formats
identical, making things a lot easier on implementors and humans editing
zone files. I see no strong reason to merge these two things into one
RRTYPE of CTA.

Paul

---

From: "Dickson, Brian" <[email-masked]>
Date: Thu, 3 Oct 2013 03:12:56 +0000

On 10/2/13 10:24 PM, "Paul Wouters" <[email-masked]> wrote:

>> Anyway, we have finally rev'ed the CDS draft, and have (I think)
>>arrived at a compromise that will be acceptable to both views (DS vs
>>DNSKEY).
>>
>> This allows children to present DS to those parents who want DS, and
>>DNSKEY to those who would prefer to calculate DS on their children's
>>behalf.
>

There is the issue of "big zone operators would need to do twice as many
queries".

There is another reason, less obvious:

What if someone puts both types in their zone?

Admittedly there are the possible cases of CTA records of both flavors,
but that is much less likely to occur deliberate or accidentally, than
having both CDS and CDNSKEY.

Copy/paste, file merge, script errors - all have non-zero chance of "same
record format" => "conflicting entries" occurring.
On the other hand, the odds of someone writing a script, or
copying/pasting, into a DIFFERENT format, are near zero.

In this case, different format is a feature, not a bug. :-)

Brian
(not one of the authors)

---

From: Paul Wouters <[email-masked]>
Date: Wed, 2 Oct 2013 23:35:37 -0400 (EDT)

> There is the issue of "big zone operators would need to do twice as many

Why? The big zone operators only need to support one type - the type
that matches their policy. If they need a DNSKEY, they look for CDNSKEY.
If they need a DS, they look for CDS.

> What if someone puts both types in their zone?

Ignore both?

> having both CDS and CDNSKEY.

I'm not sure about that.

> In this case, different format is a feature, not a bug. :-)

Using dig to check child and parent is a better feature :P

Paul

---

From: "Guangqing Deng" <[email-masked]>
Date: Thu, 3 Oct 2013 11:59:39 +0800

> > What if someone puts both types in their zone?

Maybe the parent zone needs a policy to always choose one and only one kind 
of RR (either CDS or CDNSKEY) and omit the other in this situation. 

> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

Guangqing Deng
cnnic

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 03 Oct 2013 08:45:30 +0200

Hi,

First of all. I strongly agree with Paul: keep the record formats identical.

Second: Why the name change? I assume the TA in CTA stands for Trust
Anchor. The name CDS seems to fit better even in the DNSKEY case. After
all, we are talking about the synchronizing the Delegation Signer, not a
Trust Anchor.

>> >> zone files. I see no strong reason to merge these two things into one

Merging does not necessarily mean different record formats for DS and
DNSKEY. As said earlier, the RDATA can be one selector field + DNSKEY RDATA.

example.com. 86400 IN CDS 0 257 3 5 AQPSKmyn...
                            ^^^^^^^^^^^^^^^^^^^
                            DNSKEY RDATA

> of RR (either CDS or CDNSKEY) and omit the other in this situation.

Exactly that.

Best regards,
  Matthijs

> ------------------------------------------------------------------------
> Guangqing Deng
> cnnic 
> 
>

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 3 Oct 2013 12:29:25 -0400

> So, in summary, we believe that CSYNC and CTA are related, complementary solutions, but solving different use cases. We do not think that coupling them together (nor trying to explain them both in…
Warren,

Thanks for this summary. It does appear they are complemntary solutions, 
and should not be coupled.

I suggest we move forward moving in this direction unless there is some 
staunch reaction.

tim

---

From: Warren Kumari <[email-masked]>
Date: Thu, 3 Oct 2013 15:38:34 -0400

> First of all. I strongly agree with Paul: keep the record formats identical.

Ok, I just want to make completely sure I understand (so I make sure that I'm correctly capturing things in the draft).

We would have 2 RRs, one of CDS and one of CDNSKEY.

CDS is as described in the earlier version of the doc.
example.com. 86400 IN CDS 31589 8 1 3490A6806D47F17A34C29E2CE80E8A999FFBE4BE

and CDNSKEY is:
example.com. 86400 IN CDNSKEY 57 3 8 AwEAAeikvxboZpn9VCxm3YDLHo40SvA9EmRwJHHQyJ0OCzrQSRBSipoj rW7yESXWiDDyzflS8rgzDs7M3fIdSduOdyNi55DmXPdkS8HYORTMNyzF sSOg+xx6tUySK2p4WAhlbsJNLz4IkQCek59NoDBOLyQ15npsr7Tgfb/H HU7zmCMvnxh0SqO2lyhnQfk29Thc3nC4KNJNb3drjWKOuCw5mg+2GrEZ Yc/VqdeGvrOCQ2el8jWZpSU5cxb7EdEy4B9nEeZiBpHXaZ5XJ+ewi4vm cUK5/445mGJqV4rDeicy5/ShC/BJ81v3bIRPWebvDRJmDbjr2d9MnLXU E7yyETrQd18=

Parents who want DS poll (or whatever) for CDS, parents who want DNSKEY poll (or whatever) for CDNSKEY.

Hopefully I'm understanding, because this seems much cleaner, simpler and more elegant than the CTA stuff that I described. 
So, is this what folk would like? If not, apologies for being dim...

So,  if seems that if children are not sure which one their parent wants, they *could* just publish both. If they *do* publish both, they should make sure that they are consistent. Parents should *not* check both and perform a constancy check (avoids all sorts of corner cases, old records, etc).

> all, we are talking about the synchronizing the Delegation Signer, not a

Yup -- I changed it to try and make it clear that this was a different format to the original CDS record, and avoid the "Hang on, did you mean in the CDS record described in version -00 through version -03, or the CDS that was in -04, or something else?!" problem. I also didn't want those parents who want DNSKEY to feel that that this was primarily about DS and that their use case was less important. I may have been being overly sensitive.  CTA is a crappy name (I much preferred CDS), and will more than happily s/CTA/CDS/g :-P

W

--
It is impossible to sharpen a pencil with a blunt axe.  It is equally vain
to try to do it with ten blunt axes instead.
    --  E.W Dijkstra, 1930-2002

---

From: Paul Wouters <[email-masked]>
Date: Thu, 3 Oct 2013 16:06:39 -0400 (EDT)

> So, is this what folk would like? If not, apologies for being dim...

Yes.

Paul

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 04 Oct 2013 07:51:03 +0200

On 10/03/2013 10:06 PM, Paul Wouters wrote:
>> Ok, I just want to make completely sure I understand (so I make sure
>> that I'm correctly capturing things in the draft).
>>
>> example.com. 86400 IN CDNSKEY 57 3 8
>> AwEAAeikvxboZpn9VCxm3YDLHo40SvA9EmRwJHHQyJ0OCzrQSRBSipoj
>> rW7yESXWiDDyzflS8rgzDs7M3fIdSduOdyNi55DmXPdkS8HYORTMNyzF
>> sSOg+xx6tUySK2p4WAhlbsJNLz4IkQCek59NoDBOLyQ15npsr7Tgfb/H
>> HU7zmCMvnxh0SqO2lyhnQfk29Thc3nC4KNJNb3drjWKOuCw5mg+2GrEZ
>> Yc/VqdeGvrOCQ2el8jWZpSU5cxb7EdEy4B9nEeZiBpHXaZ5XJ+ewi4vm
>> cUK5/445mGJqV4rDeicy5/ShC/BJ81v3bIRPWebvDRJmDbjr2d9MnLXU E7yyETrQd18=
>>
>> Hopefully I'm understanding, because this seems much cleaner, simpler
>> and more elegant than the CTA stuff that I described.

And no.

We could introduce a separate RRtype for synchronizing DS with DNSKEY
material: CDNSKEY.

We could also reuse the CDS RRtype. Than for parents who want DS poll:

example.com. 86400 IN CDS *1* 257 3 8
AwEAAeikvxboZpn9VCxm3YDLHo40SvA9EmRwJHHQyJ0OCzrQSRBSipoj
rW7yESXWiDDyzflS8rgzDs7M3fIdSduOdyNi55DmXPdkS8HYORTMNyzF
sSOg+xx6tUySK2p4WAhlbsJNLz4IkQCek59NoDBOLyQ15npsr7Tgfb/H
HU7zmCMvnxh0SqO2lyhnQfk29Thc3nC4KNJNb3drjWKOuCw5mg+2GrEZ
Yc/VqdeGvrOCQ2el8jWZpSU5cxb7EdEy4B9nEeZiBpHXaZ5XJ+ewi4vm
cUK5/445mGJqV4rDeicy5/ShC/BJ81v3bIRPWebvDRJmDbjr2d9MnLXU E7yyETrQd18=

and parents who want DNSKEY poll:

example.com. 86400 IN CDS *0* 257 3 8
AwEAAeikvxboZpn9VCxm3YDLHo40SvA9EmRwJHHQyJ0OCzrQSRBSipoj
rW7yESXWiDDyzflS8rgzDs7M3fIdSduOdyNi55DmXPdkS8HYORTMNyzF
sSOg+xx6tUySK2p4WAhlbsJNLz4IkQCek59NoDBOLyQ15npsr7Tgfb/H
HU7zmCMvnxh0SqO2lyhnQfk29Thc3nC4KNJNb3drjWKOuCw5mg+2GrEZ
Yc/VqdeGvrOCQ2el8jWZpSU5cxb7EdEy4B9nEeZiBpHXaZ5XJ+ewi4vm
cUK5/445mGJqV4rDeicy5/ShC/BJ81v3bIRPWebvDRJmDbjr2d9MnLXU E7yyETrQd18=

Parents who do DS poll would still have to create the DS record, but at
least the child can signal which hash has to be used.

Best regards,
  Matthijs

---

From: Warren Kumari <[email-masked]>
Date: Fri, 4 Oct 2013 09:23:25 -0400

> least the child can signal which hash has to be used.

But no, because now the parents who want DS are not getting DS -- they are getting DNSKEY.
This also doesn't satisfy the desire for standby keys (which perhaps we have been talking past each other about).
Some children want to be able to publish a DS record, but not expose the DNSKEY until they start using it -- the method you have described doesn't allow for that…

W

--
"Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life." -- Terry Pratchett

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 4 Oct 2013 09:31:56 -0400

> least the child can signal which hash has to be used.

Matthijs and Paul 
I insisted on renaming the CDS to CTA in the last version just so we can clearly talk about options. 

Strictly speaking we have 6 possible ways forward
	1) DNSKEY only 
	2) CDS as DS 
	3) CDS + CDNSKEY as separate RR types
	4) CTA that can include both DS and DNSKEY as RDATA
	5) CDS + DNSKEY 
	6) Do not standardize this is too hard/controversial ?

Each one of these has advantages and disadvantages. guess the next step is to create a table of pro's and con's of each one. 
What criteria should be in the table? 

	Olafur

---

From: Warren Kumari <[email-masked]>
Date: Fri, 4 Oct 2013 10:35:26 -0400

> Strictly speaking we have 6 possible ways forward

Doesn't allow for those parents who actually want a pre-digested DS. Also doesn't allow for backup / hidden DNSKEY option.

> 	2) CDS as DS 

This was my original preferred option -- but, doesn't handle e.g .NL who want a DNSKEY.

> 	3) CDS + CDNSKEY as separate RR types

This is currently my preferred option -- only disadvantage I can think of is burning 2 RRtypes.

> 	4) CTA that can include both DS and DNSKEY as RDATA

Yeah, That's what currently is in the document. This seems (to me at least) to be the ugliest option.

> 	5) CDS + DNSKEY 

Huzzawhat? Publish a DS in a CDS and require that the DNSKEY also exist? I don't understand what you are proposing.

> 	6) Do not standardize this is too hard/controversial ?

Nah. I think #3 is the best option, followed by #2. This doesn't seem that hard to me, nor that controversial -- we just have folk who have different desired for what they want to publish (DS / DNSKEY). I think that we can easily accommodate both camps with #3, or (less preferred) #2.

> What criteria should be in the table? 

1: Covers publishing both DS and DNSKEY
2: Ease of implementation
3: Elegance / lack of ugliness (somewhat subjective).

I'm planning on just tossing the CDS and CDNSKEY option into the draft on a plane this afternoon, and folk can have a look and see how they feel about this. To my mind the CDS + CDNSKEY seems by far the cleanest option.

W

--
It's a mistake trying to cheer up camels. You might as well drop meringues into a black hole. -- Terry Prachett

---

From: Warren Kumari <[email-masked]>
Date: Sat, 5 Oct 2013 11:55:51 -0700

> I'm planning on just tossing the CDS and CDNSKEY option into the draft on a plane this afternoon, and folk can have a look and see how they feel about this. To my mind the CDS + CDNSKEY seems by fa…

Done. 

I have just published -05. 
This version has both the CDS and CDNSKEY records, and some rules for what you do with them.

I personally find this the most attractive option -- it allows those who want DS to accept DS and those who prefer DNSKEY to take DNSKEY.  It keeps the record formats identical to the records that they represent (which, IMO makes implementation simpler), etc.

So, would like to get some feedback on this version -- I understand that it might not please everyone, such is the nature of compromise.

W

Filename:	 draft-kumari-ogud-dnsop-cds
Revision:	 05
Title:		 Automating DNSSEC delegation trust maintenance
Creation date:	 2013-10-05
Group:		 Individual Submission
Number of pages: 17
URL:             http://www.ietf.org/internet-drafts/draft-kumari-ogud-dnsop-cds-05.txt
Status:          http://datatracker.ietf.org/doc/draft-kumari-ogud-dnsop-cds
Htmlized:        http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-05
Diff:            http://www.ietf.org/rfcdiff?url2=draft-kumari-ogud-dnsop-cds-05

Abstract:

--
"Go on, prove me wrong. Destroy the fabric of the universe. See if I care."  -- Terry Prachett

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 07 Oct 2013 09:59:10 +0200

> But no, because now the parents who want DS are not getting DS -- they are getting DNSKEY.

My understanding was that the reason why parents want DS is so that the
child can determine the hash digest to be used.

> This also doesn't satisfy the desire for standby keys (which perhaps we have been talking past each other about).

CDS with DNSKEY RDATA works identical to CDS with DS RDATA. The only
difference is that the way the information is published is different. So
it does allow for standby keys.

> Some children want to be able to publish a DS record, but not expose the DNSKEY until they start using it -- the method you have described doesn't allow for that…

Why would you not want to expose the DNSKEY that you are going to use?

Personally, I find these arguments weak. But if these are important for
people, the next best solution would be two RRtypes: CDS and CDNSKEY.

Best regards,
  Matthijs

---

From: Doug Barton <[email-masked]>
Date: Tue, 08 Oct 2013 09:53:45 -0700

Responding to a message at random ...

With respect to all of those who are involved and highly motivated in 
this topic I continue to think that it is a solution in search of a 
problem. The DNSKEY needs to be in the child zone, and we know that 
parents have varying requirements for how they handle the DS record(s). 
Further, it's not at all clear that the gTLD RRA framework is even going 
to allow direct communication between the parent registry and the child 
domain holder*.

What's actually missing is a signaling mechanism from the child to the 
parent. It's not clear that DNS is able to provide this solution. But if 
it turns out that it can, a more general mechanism would provide a lot 
more utility (ROI) so the ability to handle DNSKEY and NS at least, 
along with an extensible mechanism to handle what other records may come 
down the pike which need to be coordinated between parent and child.

Doug

* Yes, I realize that there would be utility for child domains within 
the same organization, but I don't think that the limited amount of 
utility makes it worth the effort.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 8 Oct 2013 14:13:26 -0400 (EDT)

On Tue, 8 Oct 2013, Doug Barton wrote:

> parent.

Google for "timers versus triggers". We had that discussion years ago.
It ended up in a stalemate and we continued on the bases that we should
put the message in the zone because there was no agreement on how or
whom should do the work when. By putting the data in the, a zone reload
can trigger a push, and a parent can do a check based on its own timers.

Additionally, any other type of trigger signaling needs some new port
that's not port 53 or some parental server that is not the production
TLD server to answer to the trigger. TLDs weren't willing to do either.

So I disagree. We do not need a new signaling mechanism.

Paul

---

From: Doug Barton <[email-masked]>
Date: Tue, 08 Oct 2013 11:48:39 -0700

> Google for "timers versus triggers". We had that discussion years ago.

I know, I've followed the thing from the beginning. :)

> whom should do the work when.

I understand that you (and a few others) are highly motivated to create 
something in this space. However I think a reasonable conclusion from 
the stalemates that have arisen from all of the previous attempts over 
the years would be, "There is no agreement on how to proceed, so we 
should not proceed."

> By putting the data in the, a zone reload

But have we any evidence that if created, this mechanism will be used? I 
personally don't subscribe to the "If we build it, they will come" 
school of engineering. We have too many counterexamples in the DNS already.

> So I disagree. We do not need a new signaling mechanism.

I think what we disagree on is the overall utility of the project 
(again, with all due respect to the good intentions of those 
involved/interested).

Doug

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Oct 2013 12:52:14 -0700

On Oct 8, 2013, at 11:48 AM, Doug Barton <[email-masked]> wrote:

> However I think a reasonable conclusion from the stalemates that have arisen from all of the previous attempts over the years would be, "There is no agreement on how to proceed, so we should not proceed."

That is the opposite of the feeling that I got from the DNSOP meeting in Berlin.

> But have we any evidence that if created, this mechanism will be used?

IIRC, there were at least a few TLD operators at the DNSOP WG in Berlin who indicated they would strongly consider it.

> I personally don't subscribe to the "If we build it, they will come" school of engineering. We have too many counterexamples in the DNS already.

That's fine; neither you or I (currently) run a TLD and we don't have to think about it yet. This is for the people do run TLDs, and the multitude who are going to be doing so soon.

--Paul Hoffman

---

From: Doug Barton <[email-masked]>
Date: Tue, 08 Oct 2013 13:10:13 -0700

> That is the opposite of the feeling that I got from the DNSOP meeting in Berlin.

... and yet, there is a larger world outside the select few able to 
attend the meetings. :)  One could even reasonably argue that the 
opinion of those who do attend the meetings is of questionable 
statistical validity due to volunteer bias.

> IIRC, there were at least a few TLD operators at the DNSOP WG in Berlin who indicated they would strongly consider it.

Translated, "The idea does not suck so much that we feel comfortable 
rejecting it out of hand, but we have no real interest in it."

> That's fine; neither you or I (currently) run a TLD and we don't have to think about it yet. This is for the people do run TLDs, and the multitude who are going to be doing so soon.

... which leads back to my previously expressed concern that the gTLD 
RRA framework may specifically prevent this kind of child-to-parent 
signaling from being possible.

To save everyone time and further responses, I've seen all the 
counter-arguments, and have followed the most recent thread in addition 
to the previous ones. I stand by my analysis that this is a solution in 
search of a problem, and that limited resources could be better spent 
elsewhere; for whatever that analysis is worth.

Doug

---

From: Warren Kumari <[email-masked]>
Date: Tue, 8 Oct 2013 13:22:29 -0700

On Oct 8, 2013, at 1:10 PM, Doug Barton <[email-masked]> wrote:

> ... and yet, there is a larger world outside the select few able to attend the meetings. :)  One could even reasonably argue that the opinion of those who do attend the meetings is of questionable statistical validity due to volunteer bias.
> 
> Translated, "The idea does not suck so much that we feel comfortable rejecting it out of hand, but we have no real interest in it."
> 
> ... which leads back to my previously expressed concern that the gTLD RRA framework may specifically prevent this kind of child-to-parent signaling from being possible.

Which is why the draft specifically talks about parental agents:
Parental Agent: "The entity that the child has relationship with,
      to change its delegation information."

and Appendix A has:
For example in many of the TLD cases there is the RRR model
   (Registry, Registrar and Registrant).  The Registry operates DNS for
   the TLD, the Registrars accept registrations and place information
   into the Registries database.  The Registrant only communicates with
   the Registrar; frequently the Registry is not allowed to communicate
   with the Registrant.  In that case as far as the registrant is
   concerned the Registrar == Parent.

Basically the 50'000ft view is:
In many regulatory environments (the polite way of saying where ICANN says "No!") the *registrar* will fetch the CDS / CDNSKEY and will push the updated records into the *registry* through existing mechanisms (like EPP).

W

> 
> To save everyone time and further responses, I've seen all the counter-arguments, and have followed the most recent thread in addition to the previous ones. I stand by my analysis that this is a solution in search of a problem, and that limited resources could be better spent elsewhere; for whatever that analysis is worth.
> 
> Doug
> 

--
"Have you got any previous convictions?"

"Well, I dunno... I suppose I used to believe very firmly that a penny saved is a penny earned--"
-- Terry Pratchett

---

From: Doug Barton <[email-masked]>
Date: Tue, 08 Oct 2013 13:33:02 -0700

On 10/08/2013 01:22 PM, Warren Kumari wrote:
> In many regulatory environments (the polite way of saying where ICANN
> says "No!")

Just FYI, it's not ICANN that says no. It's the registrars who do not 
want ANY channel of communication with their customers that does not go 
through them. ICANN simply provides a context around which to solidify 
the agreed upon relationships contractually.

> the *registrar*  will fetch the CDS / CDNSKEY and will
> push the updated records into the *registry*  through existing
> mechanisms (like EPP).

Right, so instead of convincing hundreds of registries you're going to 
convince thousands of registrars? And you've had exactly how much 
interest from them?

Doug

---

From: Paul Wouters <[email-masked]>
Date: Tue, 8 Oct 2013 16:34:09 -0400 (EDT)

On Tue, 8 Oct 2013, Doug Barton wrote:

> counter-arguments, and have followed the most recent thread in addition to 
> the previous ones. I stand by my analysis that this is a solution in search 
> of a problem,

Since you don't have a problem, you then do not mind this solution that
other people do think solves their problem? Or do you object to this
document moving forward for other reasons?

> and that limited resources could be better spent elsewhere;

Like implementing automated KSK rollovers? :)

Paul

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Oct 2013 09:06:08 +1100

> the agreed upon relationships contractually.

So TLD's should no longer answer DNS requests from any Registrant?
Yes that is a CHANNEL OF COMMUNICATION.

Providing a relay agent is no different to providing a nameserver
in term of interacting with the Registrant.  It is not direct
acceptance of updates.  The Registrar is still the gating entity.
This is machine to machine not person to person which is what the
intent of the agreement of no communication is about.

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 8 Oct 2013 18:18:15 -0400

Doug,

The draft is not in any way limited to the TLD and one level down it is supposed to be a generic solution. 
I think it would be great for the root zone as by using CDS/CDNSKEY all requests are publicly visible and can be verified 
by any interested party. 

	Olafur

On Oct 8, 2013, at 4:33 PM, Doug Barton <[email-masked]> wrote:

> Just FYI, it's not ICANN that says no. It's the registrars who do not want ANY channel of communication with their customers that does not go through them. ICANN simply provides a context around which to solidify the agreed upon relationships contractually.
> 
> Right, so instead of convincing hundreds of registries you're going to convince thousands of registrars? And you've had exactly how much interest from them?
> 
> Doug

---

From: Alan Clegg <[email-masked]>
Date: Tue, 8 Oct 2013 18:25:51 -0400

> I think it would be great for the root zone as by using CDS/CDNSKEY all requests are publicly visible and can be verified 

And as the administrator of a number of zones with hundreds of delegations, I want this for my own internal use.

Not TLD related.

AlanC
-- 
Alan Clegg | +1-919-355-8851 | [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Oct 2013 15:31:36 -0700

> ... and yet, there is a larger world outside the select few able to attend the meetings. :)  One could even reasonably argue that the opinion of those who do attend the meetings is of questionable…

If your view is that the only way to write a standard is after you have heard from a majority of everyone who would be affected by it, that's fine, but it is not the model that is used standards bodies like the IETF.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Tue, 8 Oct 2013 15:44:42 -0700

> And as the administrator of a number of zones with hundreds of delegations, I want this for my own internal use.

Excellent.

And does the current draft solve your use case? Do you like the  current CDS / CDNSKEY split? What would make the current draft better? 

(AKA, looking for reviews / feedback). 

W

--
She'd even given herself a middle initial - X - which stood for "someone who has a cool and exciting middle name".

    -- (Terry Pratchett, Maskerade)

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Oct 2013 09:59:00 +1100

The DNS has more than one opcode.  Why don't we just use one of
them to discover the registrar for <qname,qtype,qclass>?  If you
get back NOTIMP you fallback to traditional UPDATE to the parent.
The response to the query would be PTR record(s) to the UPDATE
server(s).

Mark

In message <[email-masked]>, Paul Hoffman writes
:
> > ... and yet, there is a larger world outside the select few able to attend 
> the meetings. :)  One could even reasonably argue that the opinion of those w
> ho do attend the meetings is of questionable statistical validity due to volu
> nteer bias.
> 
> If your view is that the only way to write a standard is after you have heard
>  from a majority of everyone who would be affected by it, that's fine, but it
>  is not the model that is used standards bodies like the IETF.
> 
> --Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 9 Oct 2013 11:00:27 +0200

[I have too many unread emails in dnsop, so excuse me if I am repeating what was said earlier.]

> 	6) Do not standardize this is too hard/controversial ?

Why just not use the DNSKEY flag bits similar to RFC5011?

E.g.

Bit 7 of the DNSKEY Flags designated as the 'SYNCHRONIZE' flag.

If this bit is set to '1', AND the 'REVOKE' Bit[RFC5011] of the
DNSKEY Flags is set to '0', AND the parent[*] operator sees
a RRSIG(DNSKEY) signed by the associated key, then the parent
MAY consider to add new DS record for this key to the parent
zone records.

If this bit is set to '1', AND the 'REVOKE' Bit[RFC5011] of the
DNSKEY Flags is set to '1', AND the parent[*] operator sees
a RRSIG(DNSKEY) signed by the associated key, then the parent
MAY consider to remove DS record for this key to be removed
from the parent zone.

O.
--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 9 Oct 2013 11:06:12 +0200

On 8. 10. 2013, at 20:13, Paul Wouters <[email-masked]> wrote:

>> What's actually missing is a signaling mechanism from the child to the parent.
> 

We also have a signaling mechanism...

We can just somewhat abuse the DNS Update mechanism to send DNS UPDATE
to parent master (from SOA) server with DNSKEYs + RRSIGs as contents
of the DNS UPDATE message.

O.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 9 Oct 2013 11:11:45 +0200

> Right, so instead of convincing hundreds of registries you're going to convince thousands of registrars? And you've had exactly how much interest from them?

I think this is the wrong forum to discuss this.  You should ask the registries and the registrars.

I don't think it's that hard to convince them – just build the software for them and say: put the EPP username/password/certificate in the configuration file and run this somewhere in your infrastructure and you'll be fine.  Similar to EPP client – Most of the registrars are just running the EPP client we wrote with some wrappers around.

I don't see this as a problem and certainly we should not stop working on CSYNC/CDS/CDNSKEY because of some hypothetical problem with registrars not willing to cooperate with registries.

O.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 9 Oct 2013 06:44:42 -0700

On Oct 9, 2013, at 4:10 AM, Billy Glynn <[email-masked]> wrote:

> 
> On 5 Oct 2013, at 19:55, Warren Kumari wrote:
> 
> Section 2.2.1
> "The proposal
>    below can operate with both models, but the child needs to be aware
>    of the parental policies."
> 
> also
> Section 6.2.1
> "The
>    DNS Parent needs to publish guidelines for the children as to what
>    digest algorithms are acceptable in the CDS record.
> "
> 
> Maybe I'm missed it... but how would a child be aware of the "parental policies"?	

Thank you, great question.

The way I had envisioned this working was that the human operating the child would "know" because they interacted with the parent when bootstrapping the relationship, and had to enter either the DS or DNSKEY.
I'm also expecting that in general CDS / CDNSKEY records will be published by tools -- the human operating the child ("human child"?) could configure the tool to do do CDS or CDSNKEY -- by default I'd expect the tool to simply publish both, but some children might have religious^W valid[0] reasons for only wanting to publish one of the other.
I'm expecting the the *huge* majority of children will just publish both, and let their parents choose whichever one they want.

This text all appeared in the most recent draft, which was written in a bit of a rush (so I could chat with folk about it at the DNS-OARC meeting / I like rev'ing docs so that folk have something concrete to look at), I'll try make this clearer in the next rev…

W

[0]: For example, there are some children who want to publish two (or multiple) DS records in their parent, and keep one of the DNSKEYs hidden / private / secret. That way, if their key is compromised they can just start signing with the new DNSKEY.

> Billy			     	

--
What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?"

    -- (Terry Pratchett, Pyramids)

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Oct 2013 09:47:49 -0400 (EDT)

> of the DNS UPDATE message.

Some TLD operators I talked to did not want UPDATEs heading towards
their existing deployment. So your signaling only works if those
TLDs can re-purpose the SOA entry to specify such a _new_ server. One
could also use a new RRTYPE for it (but prob not put it in the apex)

I still think the most transparent way of signaling the child can do
is by publishing something in their zone. It will get DNSSEC protection,
and even "transparency" by being published to anyone who cares to look.

It also requires no new firewall rules at the TLDs to let in new kind of
messages like UPDATE.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Thu, 10 Oct 2013 01:46:31 +1100

In message <[email-masked]>, Paul Wouters wr
ites:
> On Wed, 9 Oct 2013, Ondej Sur wrote:
> 

UPDATE is first and foremost a message format and can be securely
used to send change requests.  It can be used for all zones regardless
of whether they are signed or not.  Yes I know updating DS records
triggered this but there is more than DS records that need to be
updated in parent zones automatically.

If a server gets renumbered it *should* be able to update its own
address records.

We *shouldn't* have to depend on zones being signed to do this.

It should work at *all* delegation points in the DNS.

Focusing on DS/DNSKEY will lead to the wrong general solution.

Focusing on the zone being signed will lead to the wrong general solution.

Mark

---

From: Billy Glynn <[email-masked]>
Date: Wed, 9 Oct 2013 12:10:05 +0100

Section 2.2.1

"The proposal
   below can operate with both models, but the child needs to be aware
   of the parental policies."
also
Section 6.2.1
"The
   DNS Parent needs to publish guidelines for the children as to what
   digest algorithms are acceptable in the CDS record."

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 10 Oct 2013 10:11:45 +0200

> [0]: For example, there are some children who want to publish two (or multiple) DS records in their parent, and keep one of the DNSKEYs hidden / private / secret. That way, if their key is compromi…

I would expect them to use the existing mechanisms (EPP/registrar web) to publish such DS record for hidden DNSKEY.

Thus I am not convinced that we need to provide out-of-channel mechanisms for such cases.

I think that most cases would be covered by DNSKEY flags (as suggested in my previous email) and the rest can be handled via existing provisioning mechanisms.

O.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 10 Oct 2013 10:16:30 +0200

>> of the DNS UPDATE message.

Paul,

> could also use a new RRTYPE for it (but prob not put it in the apex)

It doesn't have to go directly to "registry".  The child can also send UPDATEs to registrars (authenticated by the data in the registry bootstrapped by some other channel).

> and even "transparency" by being published to anyone who cares to look.

I think that publish-in-the-child-zone and UPDATE mechanisms complement each other and it's up to parent policy if they accept UPDATE and what to do when they receive the UPDATE.  One option would be to drop the contents of UPDATE and check the child zone and pull the correct data from there.

> It also requires no new firewall rules at the TLDs to let in new kind of

Don't tell me that "oh, no, I need to add new firewall rule" argument should be a showstopper when designing new protocol.

O.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Oct 2013 13:48:03 -0400 (EDT)

> Don't tell me that "oh, no, I need to add new firewall rule" argument should be a showstopper when designing new protocol.

TLDs were very adament themselves about this. Don't shoot the messenger :)

If TLDs agree on UPDATE as the trigger mechanism as opposed to EPP, I
have no problem with it. As long as signaling by using zone content is
not blocked for another 2 years while we discuss triggers. That is, I
think it is out of scope for the timers discussion and whether to use
CDS/CDNSKEY and/or DNSKEY flag.

Paul

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 11 Oct 2013 09:50:42 +0200

>  delegations in which it is currently hard to move information from

I fully support this to go ahead, although I disagree with some parts of the document.

One (not so strong) thought – it might be actually good to split the "requirements" and the "protocol" part into separate documents.

E.g. split sections 1 and 2 (+ Appendix A) to separate 'Informational' document and create new 'Standards' document from the section 3 to the end of the document.

Some other comments:

Section 6.2 second paragraph:

I would add an recommendation to check the CDS/CDNSKEY value for <n>-consencutive CDS/CDNSKEY TTL times to ensure that the change is valid.  (Where <n> is something like <2,...> per parent local policy).

Section 6.3 third paragraph:

The usual mechanism is the NOTIFY email in the registry, and the owner of the object is notified of any change of the affected object.  Thus it seems to me that this paragraph is not needed.

Otherwise lgtm.

O.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 18 Oct 2013 09:05:01 -0700

> I fully support this to go ahead, although I disagree with some parts

I also support the document, and specifically also prefer the two
different rrtypes for it.

> One (not so strong) thought – it might be actually good to split the
> "requirements" and the "protocol" part into separate documents.

I disagree with that; I don't think there is enough of a huge
requirement set to have them separated from the solution.

-- 
Wes Hardaker
Parsons