On Mon, Jun 29, 2015 at 5:59 PM, Ralf Weber <d...@fl1ger.de> wrote: > Moin! > > On 29 Jun 2015, at 22:48, Warren Kumari wrote: >> >> 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. > > So while this might work with future root key rollovers, I think it's to > late for this one, as it requires all software (root servers and validating > resolvers) to be updated, and one concern that we have with the root key > rollover is old software.
Well, yes and no. I'd also through that there was no point in trying to get this done soon -- but then, after chatting with some folk, I have reconsidered that position... *When* exactly the root key will actually roll is still unclear -- I've heard estimates from "the middle of next year" to "sometime in 2018 or 2019". I'm starting an informal poll - my choice is July 2017. If folk send me their guesses I'll collect them and we'll figure out some sort of prize for whoever gets closest. Anyway, let's say it *is* mid-2017, just for arguments sake. Let's also say that ISC and Unbound decide to implement this (much of the logic is already in there), and have it done by mid 2016 (that's ~1year). There is a *really* long tail of people who don't upgrade their name-servers, but there are also a whole bunch who do, especially if there is a security announcement / issue that gets patched. Let's say 10% of people upgrade (note that these are not the ones that are likely to have a key-roll issue, kinda by definition). Whatever the case, at least there will be *some* visibility at the root of the people who are not likely to go "Boom". IANA can publish the _tag record for the new key, or they can just rely on RFC 5011 (note that this doesn't preclude using RFC5011) - whatever the case, there will be a signal. If they choose to publish the _tag record, it will save those people who are A: upgraded and B: unable to get large responses... > > On another note, how does that interact with the root loopback draft, where > the resolver doesn't ask the root at all, but the local copy of the root > zone? I think it is OK -- the draft-ietf-dnsop-root-loopback draft says that resolvers download the root zone and serve it on their loopbacks. Compliant resolvers will then query themselves and this will Just Work. You do lose most of the purpose of this, which is to get visibility -- but, those name-servers are not *really* querying the root, and so... well... draft-ietf-dnsop-root-loopback is also really designed for niche cases.... W [0]: This contest void where prohibited, not open to ICANN / IANA employees and their immediate families, bribery not allowed, unless I get a cut too... > > So long > -Ralf -- 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
