On 5. 10. 2013, at 20:55, Warren Kumari wrote:
> 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:
On Thu, 10 Oct 2013, Ondřej Surý wrote:
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 zo
On 9. 10. 2013, at 15:47, Paul Wouters wrote:
> On Wed, 9 Oct 2013, Ondřej Surý wrote:
>
>> 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 U
On 9. 10. 2013, at 15:44, Warren Kumari wrote:
> [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 ne
On 5 Oct 2013, at 19:55, Warren Kumari wrote:
> 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
Section 2.2.1
"The proposal
b
In message , Paul Wouters wr
ites:
> On Wed, 9 Oct 2013, Ondej Sur wrote:
>
> > 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 messa
On Wed, 9 Oct 2013, Ondřej Surý wrote:
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.
Some TLD operators I talked to did not want UPDAT
On Oct 9, 2013, at 4:10 AM, Billy Glynn wrote:
>
> On 5 Oct 2013, at 19:55, Warren Kumari wrote:
>
>> 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-dns
On 8. 10. 2013, at 22:33, Doug Barton wrote:
>> 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 re
On 8. 10. 2013, at 20:13, Paul Wouters wrote:
> On Tue, 8 Oct 2013, Doug Barton wrote:
>
>> What's actually missing is a signaling mechanism from the child to the
>> parent.
>
> Google for "timers versus triggers". We had that discussion years ago.
> It ended up in a stalemate and we continue
[I have too many unread emails in dnsop, so excuse me if I am repeating what
was said earlier.]
On 4. 10. 2013, at 15:31, Olafur Gudmundsson wrote:
> Matthijs and Paul
> I insisted on renaming the CDS to CTA in the last version just so we can
> clearly talk about options.
>
> Strictly speaki
In message <201310090829392414...@cnnic.cn>, "Guangqing Deng" writes:
>
> >From: Andrew Sullivan
> >Date: 2013-10-09 07:57
> >To: dnsop
> >Subject: Re: DNSOP CDS and/or CDNSKEY
> >On Wed, Oct 09, 2013 at 10:13:53AM +1100, Mark Andrews wrote:
>From: Andrew Sullivan
>Date: 2013-10-09 07:57
>To: dnsop
>Subject: Re: [DNSOP] CDS and/or CDNSKEY
>On Wed, Oct 09, 2013 at 10:13:53AM +1100, Mark Andrews wrote:
>> I would use whois for this discovery but the response is free form
>> text and you have the whole whois
On Wed, Oct 09, 2013 at 10:13:53AM +1100, Mark Andrews wrote:
> I would use whois for this discovery but the response is free form
> text and you have the whole whois server discovery problem to deal
> with.
This sounds like an excellent reason to contribute to the rapid
specification and deployme
Mark Andrews writes:
>
> The DNS has more than one opcode. Why don't we just use one of
> them to discover the registrar for ? 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).
I would use w
The DNS has more than one opcode. Why don't we just use one of
them to discover the registrar for ? 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 , Paul Hoffman writes
:
> On Oc
On Oct 8, 2013, at 3:25 PM, Alan Clegg wrote:
>
> On Oct 8, 2013, at 6:18 PM, Olafur Gudmundsson wrote:
>
>> 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
On Oct 8, 2013, at 1:10 PM, Doug Barton wrote:
>> 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
>
On Oct 8, 2013, at 6:18 PM, Olafur Gudmundsson wrote:
> 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
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,
In message <52546bfe.7050...@dougbarton.us>, Doug Barton writes:
> 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 o
On Tue, 8 Oct 2013, Doug Barton wrote:
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,
Since you don't have a pr
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 simp
On Oct 8, 2013, at 1:10 PM, Doug Barton wrote:
> On 10/08/2013 12:52 PM, Paul Hoffman wrote:
>> On Oct 8, 2013, at 11:48 AM, Doug Barton wrote:
>>
>>> However I think a reasonable conclusion from the stalemates that have
>>> arisen from all of the previous attempts over the years would be, "T
On 10/08/2013 12:52 PM, Paul Hoffman wrote:
On Oct 8, 2013, at 11:48 AM, Doug Barton 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 proce
On Oct 8, 2013, at 11:48 AM, Doug Barton 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
On 10/08/2013 11:13 AM, Paul Wouters wrote:
On Tue, 8 Oct 2013, Doug Barton wrote:
What's actually missing is a signaling mechanism from the child to the
parent.
Google for "timers versus triggers". We had that discussion years ago.
I know, I've followed the thing from the beginning. :)
I
On Tue, 8 Oct 2013, Doug Barton wrote:
What's actually missing is a signaling mechanism from the child to the
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 becau
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 han
On 10/04/2013 03:23 PM, Warren Kumari wrote:
>
> On Oct 4, 2013, at 1:51 AM, Matthijs Mekking wrote:
>
>> On 10/03/2013 10:06 PM, Paul Wouters wrote:
>>> On Thu, 3 Oct 2013, Warren Kumari wrote:
>>>
Ok, I just want to make completely sure I understand (so I make sure
that I'm correctly
On Oct 4, 2013, at 7:35 AM, Warren Kumari wrote:
>
> 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.
>
Done.
I ha
On Oct 4, 2013, at 9:31 AM, Olafur Gudmundsson wrote:
>
> On Oct 4, 2013, at 1:51 AM, Matthijs Mekking wrote:
>
>> On 10/03/2013 10:06 PM, Paul Wouters wrote:
>>> On Thu, 3 Oct 2013, Warren Kumari wrote:
>>>
Ok, I just want to make completely sure I understand (so I make sure
that
On Oct 4, 2013, at 1:51 AM, Matthijs Mekking wrote:
> On 10/03/2013 10:06 PM, Paul Wouters wrote:
>> On Thu, 3 Oct 2013, Warren Kumari wrote:
>>
>>> 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
On Oct 4, 2013, at 1:51 AM, Matthijs Mekking wrote:
> On 10/03/2013 10:06 PM, Paul Wouters wrote:
>> On Thu, 3 Oct 2013, Warren Kumari wrote:
>>
>>> 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
On 10/03/2013 10:06 PM, Paul Wouters wrote:
> On Thu, 3 Oct 2013, Warren Kumari wrote:
>
>> 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
On Thu, 3 Oct 2013, Warren Kumari wrote:
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
On Oct 3, 2013, at 2:45 AM, Matthijs Mekking wrote:
> Hi,
>
> 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 a
On 10/2/13 5:33 PM, Warren Kumari wrote:
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.
Warren,
Thanks for th
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
Tr
> On Thu, 3 Oct 2013, Dickson, Brian wrote:
> >>> 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
> >> identi
On Thu, 3 Oct 2013, Dickson, Brian wrote:
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 10/2/13 10:24 PM, "Paul Wouters" wrote:
>On Wed, 2 Oct 2013, Warren Kumari 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).
>>
>> The 50'000ft[0] view is that the record is now a sel
On Wed, 2 Oct 2013, Warren Kumari 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).
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
On Sep 27, 2013, at 1:53 AM, Matthijs Mekking wrote:
> Hi Warren,
>
> On 09/27/2013 04:27 AM, Warren Kumari wrote:
>>
>> On Sep 26, 2013, at 12:05 AM, Matthijs Mekking
>> wrote:
>>
>>> Hi,
>>>
>>> I thought it would be good to start a thread about CDS or CDNSKEY,
>>> given the recent discus
Hi Warren,
On 09/27/2013 04:27 AM, Warren Kumari wrote:
>
> On Sep 26, 2013, at 12:05 AM, Matthijs Mekking
> 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 mee
On Sep 26, 2013, at 12:05 AM, Matthijs Mekking 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 a
Hi,
I thought it would be good to start a thread about CDS or CDNSKEY, given
the recent discussion on dnssec-deployment.
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. It's drawback however is tha
47 matches
Mail list logo
