[dns-operations] Why roll the KSK? (was Sad news today: systemd-resolved to be deployed in Ubuntu 16.10)

[David Conrad]

Paul,


On Jun 6, 2016, at 2:31 PM, Paul Vixie <vixie at tisf.net> wrote:
> Andrew Sullivan wrote:
> ...
>> It's important to recall that RFC 5011 was chosen from an array of
>> competing proposals according to a requirements document that DNSEXT
>> produced something like 10 years ago.  There's something instructive
>> in that, because the requirements were conceived in an environment
>> quite different from the one where we are.  Perhaps this suggests
>> that, in developing standards, requirements documents can do as much
>> harm as good: it's hard actually to understand requirements of a
>> system you haven't really built yet.
> 
> +1. as the author of a competing proposal, i'm not bitter, but i do wish that the WG had insisted on multiple interoperable implementations including at least one in open source, for each proposal, and insisted on a connect-a-thon style bakeoff, before choosing a winner.

I too am a bit disappointed the old school approach towards interoperable standards appears not to be en vogue, but the Internet is a different place these days. However, back when we did the 5011 vendor tests in 2014, all known 5011 implementations seemed to work fine if they were configured correctly.  The interesting bit is figuring out if things are configured correctly before the attempted roll...

> yeti-dns is about to start its first KSK roll experiment, using RFC 5011. i expect to be enlightened, one way or the other, by the results.

Any idea how many validating resolvers will be participating in the experiment?

Out of curiosity, how is it different than http://keyroll.systems or https://icksk.dnssek.info/fauxroot.html?

Regards,
-drc
(speaking only for myself)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160606/cf7f3ee1/attachment.sig>