Does BIND support "conservative" (RFC 6781, sec 4.1.4) algorithm rollovers?

[Mark Andrews]

Michael,
	there has never been needed to pre-publish RRSIGs because the DNS is
a loosely coherent system and from outside you can’t determine which DNSKEY
RRset signed which other RRset.  There is only one regularly lookup where you
can determine whether the RRset is signed by all the algorithms in the DNSKEY
RRset and that is for the DNSKEY RRset itself.  For every other regular lookup
it is impossible to determine because you have a DNSKEY RRset and seperate
RRset that may or may not have come from the same instance of the zone.  The
validation rules where designed to allow answers from different instances of
a zone to be validated.

It is this indeterminism that allows BIND to incrementally sign zones when
introducing new DNSKEY algorithms.

Supporting pre-publishing RRSIGs just complicates code for no good reason
so it is not supported.

Mark

> On 31 Aug 2021, at 10:39, Michael Sinatra <michael at brokendns.net> wrote:
> 
> Hi,
> 
> I have, in the past, used the "conservative" approach to performing algorithm rollovers for various domains.  For many domains, this is probably overkill, but I'd prefer to have the option of doing it, especially for those mission-critical domains where you really don't want to rely simply on the hope that nobody who needs to reach you (or your org/company) is using a resolver that is still following the strictest interpretation of RFC 4035, section 2.2.
> 
> In the past, I have handled this completely manually, signing the zone using dnssec-signzone to sign the zone with keys of both algs before (again manually) including the the new alg keys in the DNSKEY RRSET. But for zones which I am inline-signing as a provider for someone else, I would like to use a more automated method.  It doesn't appear that BIND currently supports this, either with dnssec-keymgr and 'inline-signing' or with KASP.
> 
> I did try the trick of setting the key metadata manually ('publish' in the future and 'activate' in the past), but BIND 'inline-signing' would not sign the zone prior with the key prior to its publication, despite my timing metadata settings.
> 
> So I am assuming that only the "liberal" approach is supported.  One thing I thought of was trying a "moderate" approach, where the various TTLs are manipulated so that the zone RRSIGs expire quickly before the new alg is added and then flipping it so that the DNSKEY RRSET expires quickly and the zone/RRSIG TTLs stay in cache longer.  But that is still a fairly tricky approach and I am not sure it would work...
> 
> michael
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> 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