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

[Michael Richardson]

Matthew Pounsett <matt at conundrum.com> wrote:
    >> 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.

    > 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 at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- 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/20190405/b476d1c1/signature.asc>