On Thu, 28 Jan 2010, Mark Andrews wrote: > The DNSKEY RRset size seems small for testing. We really should > be looking the biggest key set sizes that occur during rollover > simultaneous ZSK/KSK rollovers. Hopefully that is in the planning.
The design allows for ZSK rollovers at calendar quarter boundaries and KSK rollovers in the middle of a quarter, which are intentionally non-overlapping so that the are never more than three keys in the root DNSKEY RRset. (Please see the diagram on page five of http://www.root-dnssec.org/wp-content/uploads/2009/12/draft-icann-dnssec-arch-v1dot2dot1.pdf, which Tony already referred to.) There will be a ZSK rollover at the end of Q1/start of Q2 and a KSK rollover in the middle of Q2. But because the signed root currently being published has deliberately obscured key material, essentially only the key IDs will change: the DNSKEY RDATA will contain the same human-readable base64[*], padded to produce the same key ID as the actual, non-published key. So there will be periods between now and the anticipated completion of deployment on July 1 when the root key set will contain two ZSKs and one KSK, and one ZSK and two KSKs. On Wed, 27 Jan 2010, Stephan Lagerholm wrote: > And a revoked key with flag "385" as the high level design calls for RFC > 5011 compatible rollovers. The KSK rollover in mid-Q2 will use RFC 5011 semantics, as will every KSK rollover. (But since the KSK is 2048 bits, I hope to not see a rollover of the initial published KSK for a long time.) On Thu, 28 Jan 2010, Tony Finch wrote: > The key rollover timetable staggers ZSK and KSK rollovers. See page 5 of > http://www.root-dnssec.org/wp-content/uploads/2009/12/draft-icann-dnssec-arch-v1dot2dot1.pdf > However that document is a bit light on emergency procedures. That's a high-level architecture document and intentionally doesn't cover every detail. There is much more detail in the policy and practice statements (one each for VeriSign and ICANN at http://www.root-dnssec.org/documentation), including detail about emergency key rollovers. Is there something missing, in your opinion? Matt [*] $ dig +nocmd +noquestion +nocomments +nostats @l.root-servers.net dnskey . . 86400 IN DNSKEY 256 3 8 AwEAAa1Lh++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ +++++++8 . 86400 IN DNSKEY 257 3 8 AwEAAawBe++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++8= _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
