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. It would be nice if we could use the root NS hints as the list of IPs, with some kind of redirect of the relevant port (80?) to another machine, but I don't think that's a load I want the anycast root name servers to support. > Not that whatever you're thinking was necessarily only applicable to the root > zone, but I mention this in the hopes that people keep it in mind. If we want > to try to add something like a chain of old keys signing each other, it > probably needs to be at an off-apex special name (underscores! yay!) or use a > new type that is DNSKEY-like, but for a special purpose. If you change the thing to non-DNSKEY, then the signatures have to change. There is an advantage to just leaving things literally (byte for byte) as they are/were. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-