[ksk-rollover] Starting discussion on acceptable criteria for proceeding with the root KSK roll

David Conrad david.conrad at icann.org
Fri Jan 5 01:12:10 UTC 2018


Yazid,

On January 4, 2018 at 1:24:23 PM, Yazid AKANHO via ksk-rollover (ksk-rollover at icann.org<mailto:ksk-rollover at icann.org>) wrote:
What i suggest is that we must have an estimation of how many end users will be isolated from Internet if we go for the rollover now and how many resolvers still have KSK-2010 only at the current date. Knowing those data should be a good reference point.

Through RFC 8145, we have a whiff of a hint about the 2nd, but it is highly questionable as it only shows up with folks who keep their name servers up to date and those are probably not the folks we have to worry about having misconfigurations (the fact that a surprising percentage of these folks _were_ misconfigured is interesting).

We don’t have good data for the first and I’m not sure how we can get it.

 Then, ICANN can continue contacting the administrators,

This has not been particularly successful, at least with the 500 IP addresses we identified from 8145 reports back in Sept.

having their awarness sessions/trainings,

We now typically get rejected when we ask to speak at conferences on the KSK rollover.

provide technical supports, ... in permanent and more intensive basis.

I’m not sure what this means.

Each end of month, ICANN can publish data for the above two KPI to see how we are globally improving to reduce the severity of impact.
Meanwhile, ICANN will put in place various emergency response technical pool of staff and choose a date for the rollover.
Those who are still not ready at the date of the rollover will be isolated from Internet and administrators must have to contact one pool of ICANN emergency response staff to get support.

To be honest, I’m not sure how this will help. Realistically (although there are people who will and have argued “people will die!” if applications get answers they don’t expect), I suspect the problem isn’t recovery from KSK rollover-induced failures — that’s easy, you just turn off DNSSEC validation in your resolver, or, if you’re clueful, update your trust anchor. The problem is the longer term impact on trust in DNSSEC: not only do authoritative server operators cause outages when they’ve enabled DNSSEC, but now, resolver operators cause outages.

Regards,

-drc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20180105/8414b949/attachment-0001.html>


More information about the ksk-rollover mailing list