[ksk-rollover] suggestions for deciding on key roll timing

[Evan Hunt]

My own mic comments:

1. Has there been any research yet as to how much overlap exists between
the IP addresses that were sending spurious DNSKEY queries after the
revocation, and the ones that had already been found via telemetry not to
have rolled the keys?  This information would be useful in determining how
good or bad our telemetry is.

2. Were there significant operational problems observed from the presence
of a standby key during the rollover period? (Geoff said yes, there was
some impact measured; Paul noted it did not rise to the level of complaints
to ICANN.) Given that the effect seems to have been modest, I'd like to
suggest reconsideration of the decision not to have a standby key in the
zone except during key rolls.

3. A likely candidate for at least some of the spurious DNSKEY traffic
is a bug in BIND that was fixed over four years ago.  Is there anything
we can do to hasten the obsolescence of old broken servers that misbehave
during rollovers?  Would an algorithm upgrade help, perhaps?

4. While the 2018-2019 key roll did have some unexpected results, they were
quite manageable by the existing provisioning, and shouldn't frighten us
away from doing it again. Sooner is better, it gets us more data.

-- 
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.