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
