Matthew Pounsett <matt@conundrum.com> wrote: >> Matthew Pounsett <matt@conundrum.com> wrote: > Someone suggested >> keeping a set of DNSKEYs with a chain of RRSIGs in an > alternate >> zone, but that isn't scalable to multiple trust anchors unless > >> you've also got some way to signal the name of the alternate zone at >> the > apex. And then we're talking about adding a delegation to the >> root zone that > is not a TLD registry, which has its own set of >> complexities. >> >> One thought is a set of files, copies of the root zone in AXFR or DNS >> presentation format. If available via TCP at a known IP address(es), >> then the client can replay the process and roll itself forward. > That's still seems root-zone specific, though. They're not > particularly common, but there are other trust anchors out there. As > was done with 5011, it seems prudent to think about how anything we > design could be applied to other zones. That seems a reasonable goal, but if other trust anchors can be updated through the normal software update process then they may be less of a problem. If you can't resolve the root (and don't want to turn off DNSSEC), then the rest of the Internet is gone... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [