Your question is well timed. with DNSSEC keyroll happening, the question: "what level of 5011 deployement" exists is unanswerable with authority because the architects did not consider signalling of capability sufficiently trustable. So we have no direct measure of capability, and a weak, indirect sense of deployment from other signals of capabilities which would imply post-5011 capable code, but cannot say if a locally maintained hand-installed TA is in use.
So the question "is it assumed" is a good one. I think the answer is "yes, we design for the assumption DNS now is enabled for 5011, or else is owning its problems" -G On Thu, Mar 23, 2017 at 9:08 AM, Brian Dickson <brian.peter.dick...@gmail.com> wrote: > I was thinking about the DNSSEC validation by stubs, with respect to the > homenet discussion. > > And, I was wondering about various trust anchor options (other than ICANN's > current root trust anchor). > > It occurred to me, that any non-ICANN trust anchor, would possibly require > 5011 key rolls under certain circumstances. > > Which begs the question: are validating stub resolvers presumed to be > 5011-capable? > > But, I realize, the issue of 5011 capability also exists for the root trust > anchor. > > So, the dilemma is: > > Can we assume 5011 stub support regardless? > If not, does this make the DNSSEC issue for homenet moot, since the root KSK > will be rolled in the near future (for some value of "near future"), and > break stub validation? > > On the other hand, if 5011 support by stubs is assumed, there is one > interesting option: > > Establish a trust anchor for homenet (whatever name is used), AND publish > the private keys. > > This creates the ability to have a master DNS authority server, in any given > homenet instance, sign the data in the homenet zone. The default software > could/would need to ship with the trust anchor, and the private key. The > out-of-the-box behavior would just work, and would verify/validate properly > for validating stubs that ship with the homenet trust anchor. > > There would then be the ability for users running their own homenet > networks, to do the equivalent of changing the default password -- they > would be able to do a 5011 key roll, which would cause the default trust > anchor to be replaced with a unique trust anchor for that specific homenet. > > It's not part of the homenet standard (yet), but might be worth thinking > about. > > Again, the main question is, has an assumption about 5011 support in stubs > been made, and is it a valid assumption? > > If not, to re-emphasize, then the "unsigned delegation" thing isn't even > necessary, since the stub resolvers won't be able to validate ANYTHING. > > Brian > > _______________________________________________ > 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
