[ksk-rollover] alternatives to 5110 for automating roll-over

[Michael Richardson]

Matthew Pounsett <matt at 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 at sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190401/6b96c70d/signature.asc>