Re: [dnsext] historal root keys for upgrade path?

Here's an idea, which relies on "conventions" rather than "standards".
I.e. can be implemented unilaterally by $vendor, independent of anything else.

The basic idea is that DNSSEC relies on verification, and doesn't
*really* care where
the answer itself comes from.

And thus, anyone can run their own "copy" of any zone, even the root
zone, just by mirroring/copying/caching.

The scheme is, have copies of the root zone at $IPn inside $vendor's IP space.
Whenever the root zone key rolls, increment the last octet of $IPn
(thus $IP(n+1) = $IPn + 1).

The old root zone copy authenticates okay, and this creates a suitable
trust anchor for rootzone.$vendor.$tld.

The content of rootzone.$vendor.$tld is a set of new hints and copy of
the root zone trust anchor.

Following the new hints to $IPn+1 permits the new trust anchor to be verified.

I'm not sure, but I *think* this works (modulo errors or omissions).

It might be necessary to have the bootstrap start with a static trust
anchor and set of root hints inside rootzone.$vendor.$tld...

Brian

On Tue, Jan 25, 2011 at 4:47 PM, Paul Wouters <paul@xelerance.com> wrote:
> On Tue, 25 Jan 2011, Paul Hoffman wrote:
>
>>> The anser seems to be "yes". It also means that some devices will fail
>>> due to
>>> firewall rules if this updating happens outside of the DNS scope.
>>
>> I don't understand this. I proposed that the updating procedure use fixed
>> IP addresses; are you saying that there are firewalls that prevent such
>> communication unless there was a DNS lookup first?
>
> I dount many switches/routers deployed at $customer can just access a random
> $vendor IP, yes.
>
>>>> Bootstrapping is hard, but once you have done it, you can reuse the
>>>> trust logic you used to do it again.
>>>
>>> Not neccessarilly. Bootstreap happens on a desk at the sysadmin office,
>>> not
>>> neccessarilly on the switch in the production environment....
>>
>> There is no reason why it can't happen at the switch itself, assuming that
>> you have not turned off the "trust the vendor to bootstrap DNSSEC" option in
>> the switch's config.
>
> But dong tftp,http or even ssh is a much different ACL then "doing more DNS
> through the $company assigned forwarder".
>
> Paul
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
>