I agree with the sentiment that there should be a "regular" KSK Key
roll-over - probably once every five years (though I roll my KSK's once
a year).
However, I would agree that it first makes sense for this roll-over to
complete first - along with some research to understand any mishaps.
Regarding people reaching out to their own communities - anyone got an
outline of what such a communication would contain? In South Africa, up
to 50% of lookups are via DNSSEC aware recursive resolvers according to
https://stats.labs.apnic.net/dnssec - so this would seem like a worth
while exercise.
On 09/18/2018 02:46 PM, Lars-Johan Liman wrote:
I agree too.
I think we should set an "intense" schedule (twice per year? once per
year?) _beforehand_, to send the message that "there is no relief after
this, there is only more pain ahead ... unless you automate!" to the DNS
software community. There must be no way to hardcode the KSK in code.
This will continue to be this painful until that message is received and
understood.
Cheers,
/Liman
kolkman@isoc.org:
I agree with Michael, albeit I would phrase it slightly differently:
Rolling the key regularly is a strategic choise and makes a keyroll an operational reality.
How regular (or how frequent) is a tactic. Whether That is yearly, no
monthly or once half a decade is a tactic that takes into account some
of our learnings.
I would really like to see that strategic position being explicit.
Olaf.
----
Composed on mobile device, with clumsy thumbs and unpredictable autocorrect.
________________________________
From: ksk-rollover <ksk-rollover-bounces@icann.org> on behalf of Michael StJohns <msj@nthpermutation.com>
Sent: Tuesday, September 18, 2018 5:04:31 AM
To: Matt Larson
Cc: ksk-rollover@icann.org
Subject: Re: [ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover
On 9/17/2018 3:57 PM, Matt Larson wrote:
The answer I've given when people ask this question is that we need to
get through the first rollover and analyze how it goes before we can
discuss subsequent rollovers. One can imagine that how the first
rollover goes could have a material effect on the timing of the next one.
This seems like a bad approach given how that we currently have interest
and opportunity in the roll-over that could catalyze planning for a
second roll. This does not - and should not - need to be single
threaded. AFAICT, you're going to know most everything you need to
know a few seconds to a few days after you stop signing the the old key.
So - I suggest you pick a date now. Start planning for the next roll
now. If your post analysis shows a problem - adapt and overcome and
adjust the dates if you need to. It's hard to hit a target if you don't
put it on calendar.
Later, Mike
_______________________________________________
ksk-rollover mailing list
ksk-rollover@icann.org
https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________
ksk-rollover mailing list
ksk-rollover@icann.org
https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________
ksk-rollover mailing list
ksk-rollover@icann.org
https://mm.icann.org/mailman/listinfo/ksk-rollover
--
Mark James ELKINS - Posix Systems - (South) Africa
mje@posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA:
https://ftth.posix.co.za_______________________________________________
ksk-rollover mailing list
ksk-rollover@icann.orghttps://mm.icann.org/mailman/listinfo/ksk-rollover