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

[David Conrad]

Erwin,

On January 4, 2018 at 2:33:17 PM, Erwin Lansing (erwin at dk-hostmaster.dk<mailto:erwin at dk-hostmaster.dk>) wrote:
I’ll add to that corporate culture: when DNS fails, the message from higher up will be “Make it work”, not “Make it work The Right Way”.

Agreed.

On a side note, my biggest fear has been those people/SMBs that buy a black box for some reason, which also does DNS, and has DNSSEC turned on by default, plug in into their network and forget about it, rather than, say, people that know DNS, but not really about DNSSEC.  In all your outreach, have you noticed that to be the case, or is it more e.g. service providers, where someone flipped the switch and promptly forgot about it, or something else?

I share this concern, but TBH, from my experience in the outreach I was involved with personally, the response was bimodal, either:

A) boredom, having to listen to yet another talk on stuff they’d already dealt with (e.g., NANOGs, RIPE meetings, etc)

- or -

B) incomprehension, not even knowing what the letters DNS stand for. (e.g., CIO/CTO forums, non-technical venues)

The reality is that finding the right people to speak to to ensure resolvers are properly configured for the KSK rollover turns out to be quite hard.

I have not heard anyone question the security DNSSEC provides or that postponing a rollover is reducing its security.

I’ve heard the former. I’ve yet to hear the latter except from a handful of people directly involved in DNSSEC deployment efforts.

Both postponing the rollover and doing a rollover with significant fallout, will add more fuel to the fire for those who feel DNSSEC is not a viable solution from an operational viewpoint.  All that to say, and I’m playing devils advocate here, at some point we do need to bite the bullet and do the rollover, because to keep postponing it is yet another signal that DNSSEC is not production ready.

To be very clear, we don’t want to continue postponing. What we’re looking for is for the community to tell us in the ICANN Org how to move forward. We were surprised with the 8145 data (i.e., that we were actually getting data and the number of misconfigurations we were seeing were as high as they were). We’ve done a bit of analysis and from what little we’ve been able to ascertain, there doesn’t appear to be anything fundamentally broken with the architecture or implementations, rather misconfiguration happens. This isn’t surprising. However, now that we know concretely there will be brokenness, how much is the community willing to tolerate (and what metrics can we use to ensure we’re below that threshold).

Regards,

-drc

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