Root KSK rollin', rollin', rollin'
This is the next (perhaps final?) phase of DNSSEC in the root. It's important it be treated with all the importance necessary, but also as the final experiment. After this, it's all real in a production-quality sense. I too encourage doing multiple rolls for the first two years. I don't think Steve's advise on 3 months enough time, however. Many larger ISPs have a new-version validation period that exceeds 3 months, so even if a vendor managed to get new code out the day the roll went bad, we might not see widespread deployment of new code before the next event. I fear rolling too often when running installations cannot be upgraded will cause cautious ISPs to not consider DNSSEC, or worse, disable it, when faced with angry customers and VPs, and an impending 3 month doomsday-to-their-career window. I do think 6 months is more reasonable, and attainable by all but the very slow to vet new releases. It reduces the number of "test events" but it also makes each one potentially much more useful. In the web development world, there is frequently a multi-phase release process. Developers and test systems run various system tests, and QA folk do some of their QA work. The potential release is then pushed out to a staging system, which mimics as closely as possible the actual, production world. It uses the same data (as much as practical), the same hardware type, etc. This is where the real test happens for capacity, and all the other operational issues dealing with the final deployment. Only after it has cooked enough there, will it move on to the real world. Perhaps something like this could be set up for the root, to give one last chance for developers to ensure their code will pass the smoke test? I know implementations are vetted against what they think will happen to the root, but nothing is as accurate as either a published "here is the root on day 1, 31, 61, etc" to test with, or confirmation of code working correctly, as a staging test with "production semantics." --Michael