[DNSOP] Validating stubs? Was: Re: WG review of draft-ietf-homenet-dot-03

[Brian Dickson <[e-mail]>]

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