[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.


More information about the ksk-rollover mailing list