BIND9 DNSSEC algorithm rollover for inline-signed zone

[Mark Andrews]

In message <20161007164742.GA18356 at danton.fire-world.de>, Sebastian Wiesinger writes:
> * Mark Andrews <marka at isc.org> [2016-10-06 23:33]:
> > > is there a guide for an algorithm rollover with BIND9 for an
> > > inline-signed zone? I want to roll from RSA to ECDSA but I'm unable to
> > > find a good guide for it. I already looked at the ISC DNSSEC Guide but
> > > it doesn't seem to cover that the RRSIGs made by the new keys need to
> > > be published before the DNSKEYs themselves are published in the zone.
> > 
> > Because there is no such requirement.  Just create the keys in the
> > new algorithm and let named sign the zone.
> > 
> > The DNSSEC RFC's were written with rules for zone publishers and
> > rules for zone validators.  These were designed to around the fact
> > that the DNS is loosely coherent and that you can't update everything
> > simultaneously.  That means thay you can expect that you won't find
> > signatures for every alorithm in the DNSKEY RRset in the answers.
> 
> Thank you for explaining this for me. I was reading RFC6781, which I
> now realize is probably outdated in this regard so I was a bit
> confused.

There are multiple mechanisms.  A implementation doesn't have to
support all of them.  Prepublishing RRSIGs before publishing DNSKEYs
was not part of the design of DNSSEC.

> > Once named has completed signing the zone with the new algorithm
> > and all the slaves have the fully signed zone and the caches have
> > expired any RRsets which are only signed with the old algorithm you
> > can add DS records for the new algorithm for the zone.
> 
> This only applies when I change the DS record, right? I assume that I
> can add the new one instantly and remove the old one later when all
> caches have expired the old data.

There are always timing considerations with DNSSEC.  You prepublish
DS records or you have multiple KSKs.  You have multiple signatures
or you have multiple ZSKs.  It's all about having what you need to
validate available regardless of when the records are learnt or from
where.


> Regards
> 
> Sebastian
> 
> -- 
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
>             -- Terry Pratchett, The Fifth Elephant
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org