Atlas probes can help us we can even measure this from webpages, cellphones, OS updates can add a test etc.
Olafur On Jun 29, 2015 7:33 PM, "Warren Kumari" <war...@kumari.net> wrote: > On Mon, Jun 29, 2015 at 7:28 PM, Olafur Gudmundsson > <ola...@cloudflare.com> wrote: > > 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. > > ... and know where the nameservers are, and be able to query the > nameservers to see if they are returning the AD bit. This requires > that they are open recursive, that IANA (or someone) is able to query > them, or something similar... > > > Unless I've completely misunderstood? > > W > > > > > > 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 > > > > -- > 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
