There is much simpler way. Just add record to the rootzone that is only signed by the new key. If resolver returns AD bit it has the new key.
All that is needed is to sign a Rrset for a long time and add it at to the rootzone and make sure no ZSK signs it. Olafur On Jun 29, 2015 4:49 PM, "Warren Kumari" <war...@kumari.net> wrote: > Hi all, > > So, there is a project underway to roll the DNSSEC root key. There has > been much written about this, including SAC063 > (https://www.icann.org/en/system/files/files/sac-063-en.pdf[0]), a > DNSSEC Root KSK Rollover Plan Design Team, various consultations with > the community, many presentations at DNS-OARCs, etc. > > One of the biggest impediments to actually performing the rollover is > that some set of folk will not have performed RFC5011 style rollover, > whether because their software doesn't support 5011, because they have > statically configured a TA, because the bigger response makes them > sad, whatever. The fact that we cannot tell who has only has the old > key, and who has both makes the keyroll very scary - we cannot predict > who, and how wide scale the outage will be when the old key is > removed. > > I've written a draft that proposes a different way of performing root > key rollover that exposes who all has which key - this allows one to > know that 99.8% of resolvers have the new key, who has the old one, > and who will break. > It does this by encoding the current set of TAs that the resolver has > into a query, and using that to fetch the new keys. By watching > queries at the root one can see the population of people with each TA, > and watch that change over time. This was written for root key roll, > but is applicable to any TA in the tree. > > > I'd appreciate any feedback, the draft announcment is here: > Name: draft-wkumari-dnsop-trust-management > Revision: 00 > Title: Simplified Updates of DNS Security (DNSSEC) Trust Anchors > Document date: 2015-06-29 > Group: Individual Submission > Pages: 8 > URL: > > https://www.ietf.org/internet-drafts/draft-wkumari-dnsop-trust-management-00.txt > Status: > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-trust-management/ > Htmlized: > https://tools.ietf.org/html/draft-wkumari-dnsop-trust-management-00 > > > Abstract: > This document describes a simple means for automated updating of > DNSSEC trust anchors. This mechanism allows the trust anchor > maintainer to monitor the progress of the migration to the new trust > anchor, and so predict the effect before decommissioning the existing > trust anchor. > > It is primarily aimed at the root DNSSEC trust anchor, but should be > applicable to trust anchors elsewhere in the DNS as well. > > [ Ed note - informal summary: One of the big issues with rolling the > root key is that it is unclear who all is using RFC5011, who all has > successfully fetched and installed the new key, and, most > importantly, who all will die when the old key is revoked. A > secondary problem is that the response sizes suddenly increase, > potentially blowing the MTU limit. This document describes a method > that is basically CDS, but for the root key (or any other trust > anchor). Unlike the CDS record though, this record lives at a > special name - by querying for this name, the recursive exposes its > list of TAs to the auth server (signalling upstream) . This allows > the TA maintainer to predict how many, and who all will break. It > also allows the pre-publication of a key before using it, and so > avoids the need to double response sizes...] > > [ Ed note: Text inside square brackets ([]) is additional background > information, answers to frequently asked questions, general musings, > etc. They will be removed before publication.] > > [ This document is being collaborated on in Github at: > https://github.com/wkumari/draft-wkumari-dnsop-trust-management. The > most recent version of the document, open issues, etc should all be > available here. The authors (gratefully) accept pull requests ] > > > > W > [0]: Full disclosure: Author. > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
