[ksk-change] Capabilities of validating systems we need to consider
Doug Barton
dougb at dougbarton.email
Sun Sep 21 19:22:10 UTC 2014
On 9/21/14 8:27 AM, Paul Hoffman wrote:
> Greetings again. In thinking about the question of "what would happen if we changed the KSK", but without thinking about why and when, it would be good to think about what kinds of systems are out there. My initial list came to three categories of capabilities:
>
> 1) Able to automatically pull and correctly use a new KSK
>
> 2) Cannot automatically pull a new KSK, or cannot correctly use an automatically-pulled KSK; however, it can correctly get and use a new KSK with operator intervention
>
> 3) Even with operator intervention, cannot pull a new KSK or cannot correctly use an manually-pulled KSK
>
> Are there other categories that would look operationally different to either customers of the system or to operators of signed zones?
>
> We will certainly later debate how many systems are in these categories and if those systems are "important", but it would be good to start with the smallest complete set to talk about.
Is it worthwhile to also consider non-DNS hardware/software that is
nevertheless part of the resolution/validation chain? Off hand I'm
thinking specifically of a category of network devices that can handle
DNS packets related to the root at their current size, but that may have
"issues" if we add a new KSK, regardless of what "kind" of new KSK it is.
I'm not sure how much of an issue this will turn out to be in practice,
as theoretically every such device had its capacity tuned upwards to
handle the size of the current packets. But we already know that both
software users and vendors have problems with DNS packets that are !UDP
and/or >512 bytes. To assume that just because things work now with
packets of the current size means that they will continue to work if the
packets get larger does not seem safe to me.
Doug
More information about the ksk-rollover
mailing list