Joe Abley writes:
> I think the wider problem space might be better described as trust
> anchor publication and retrieval.
Couldn't have said it better myself (more specifically, I didn't). The
problem space is much bigger than 5011, and 5011 is but one tool to
solve a piece of the whole space.
On 1 Nov 2018, at 15:14, Wes Hardaker wrote:
> Russ Housley writes:
>
>> It is a good time to do rfc5011-bis. Real world experience from the
>> KSK roll makes a lot os sense to me.
>
> I think step one would be to list the aspects of it that worked well,
> and the aspects that didn't. From t
Russ Housley writes:
> It is a good time to do rfc5011-bis. Real world experience from the
> KSK roll makes a lot os sense to me.
I think step one would be to list the aspects of it that worked well,
and the aspects that didn't. From that we can determine the need for a
replacement and what fe
> On Oct 30, 2018, at 8:27 PM, Mark Andrews wrote:
>
>> On 31 Oct 2018, at 11:16 am, Jim Reid wrote:
>>
>> On 30 Oct 2018, at 22:31, Mark Andrews wrote:
>>>
>>> Ultra frequent key rolls are not necessary. It takes years the latest
>>> releases of name servers to make it into shipping OS’s
On 10/31/2018 2:54 PM, Paul Vixie wrote:
Jim Reid wrote:
On 31 Oct 2018, at 00:27, Mark Andrews wrote:
Bootstrap is still a issue. Over fast TA rolling makes it more of
a issue.
Indeed. And that's the underlying problem that needs to be fixed IMO
- for instance when/if there's an emerge
Hi Paul,
On 31 Oct 2018, at 14:54, Paul Vixie wrote:
> Jim Reid wrote:
>
>>> On 31 Oct 2018, at 00:27, Mark Andrews wrote:
>>>
>>> Bootstrap is still a issue. Over fast TA rolling makes it more of
>>> a issue.
>>
>> Indeed. And that's the underlying problem that needs to be fixed IMO
>> - f
Jim Reid wrote:
On 31 Oct 2018, at 00:27, Mark Andrews wrote:
Bootstrap is still a issue. Over fast TA rolling makes it more of
a issue.
Indeed. And that's the underlying problem that needs to be fixed IMO
- for instance when/if there's an emergency rollover.
bootstrappers should have
> On 31 Oct 2018, at 00:27, Mark Andrews wrote:
>
> Bootstrap is still a issue. Over fast TA rolling makes it more of a issue.
Indeed. And that's the underlying problem that needs to be fixed IMO - for
instance when/if there's an emergency rollover.
> On 31 Oct 2018, at 11:16 am, Jim Reid wrote:
>
> On 30 Oct 2018, at 22:31, Mark Andrews wrote:
>>
>> Ultra frequent key rolls are not necessary. It takes years the latest
>> releases of name servers to make it into shipping OS’s.
>
> So what? Key rollover policies cannot and should not b
Chris,
Thanks for your comments.
- Original Message -
From: "Chris Thompson"
To: "George Barwood"
Cc:
Sent: Saturday, May 22, 2010 8:07 PM
Subject: Re: [DNSOP] KSK rollover
> On May 22 2010, George Barwood wrote:
>
>>Well, I have uploaded a dra
On May 22 2010, George Barwood wrote:
Well, I have uploaded a draft :
http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-00.txt
Comments and/or indications of support are of course welome, on or off list.
Section 3:
| The CDS record MUST be signed with a Key Signing Key, that is a key
|
Well, I have uploaded a draft :
http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-00.txt
Comments and/or indications of support are of course welome, on or off list.
George
- Original Message -
From: "George Barwood"
To:
Sent: Thursday, May 13, 2010 8:56 AM
Subject: [DNSOP] KSK r
In message , Joe Abley writes
:
>
> On 2010-05-13, at 22:32, Mark Andrews wrote:
>
> > Which is essentially registrar to registry. It really does not
> > make for a general solution to the problem unless every operator
> > of every zone that delegates any zone runs epp in addition to running
>
On 2010-05-13, at 22:32, Mark Andrews wrote:
> Which is essentially registrar to registry. It really does not
> make for a general solution to the problem unless every operator
> of every zone that delegates any zone runs epp in addition to running
> a DNS server.
Sure, but be aware that you're
In message <74ae2b2b-a09a-4fbf-b6c3-7eebe89ca...@hopcount.ca>, Joe Abley writes
:
>
> On 2010-05-13, at 19:33, Mark Andrews wrote:
>
> > There are lots of way to do this.
> > * Use UPDATE to update the delegation records in the parent.
> > This would work today it only requires a w
On 2010-05-13, at 22:13, Joe Abley wrote:
> ... and there's also the approach that is actually being implemented, which
> is described in RFC 4310.
Or 5910, since that seems to exist now. :-)
Internet Engineering Task Force (IETF) J. Gould
Request for Comments: 5910
On 2010-05-13, at 19:33, Mark Andrews wrote:
> There are lots of way to do this.
> * Use UPDATE to update the delegation records in the parent.
> This would work today it only requires a willingness to do so.
> This can be done securely (TSIG) and will scale.
>
In message <44c21cd9ee514b039eafeafa707a2...@local>, "George Barwood" writes:
>
> - Original Message -
> From: "Patrik Wallstrom"
> To: "George Barwood"
> Cc:
> Sent: Thursday, May 13, 2010 9:06 AM
> Subject: Re: [DNSOP] KSK
At 17:37 +0100 5/13/10, George Barwood wrote:
I'm somewhat puzzled that thre is no specification, and apparently no
activity on this.
http://www.ripe.net/ripe/meetings/ripe-59/presentations/lewis-dnssec.pdf
There's activity. There's no standard underway because of the
plethora of situations
> That is certainly relevant to rollover, but it doesn't specify any means
> by which the new DS records can be placed in the parent zone.
You're correct, there's no mechanism for doing this within the DNS. You
need to update DS records through your registrar just as you do with NS
records and gl
- Original Message -
From: "Patrik Wallstrom"
To: "George Barwood"
Cc:
Sent: Thursday, May 13, 2010 9:06 AM
Subject: Re: [DNSOP] KSK rollover
>On May 13, 2010, at 9:56 AM, George Barwood wrote:
>> I have been thinking about KSK rollover in my
On May 13, 2010, at 9:56 AM, George Barwood wrote:
> I have been thinking about KSK rollover in my DNSSEC implementation, and it
> seems
> that there is currently no specification for KSK rollover within the DNSSEC
> protocol.
>
> There is this expired requirements draft
>
> http://tools.iet
22 matches
Mail list logo
