DNSSEC algo rollover fails to delete old keys

[Robert Wagner]

Can do to provide instructions on how to follow the upcoming post quantum cryptography requirements?

CSA_CNSA_2.0_ALGORITHMS_.PDF (defense.gov)<https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF>

It would be exteremely helpful. If the crypto is not ready yet, then please keep these standards in mind for future direction when available.


RW


________________________________
From: bind-users <bind-users-bounces at lists.isc.org> on behalf of Matthijs Mekking <matthijs at isc.org>
Sent: Wednesday, October 16, 2024 4:03 AM
To: bind-users at lists.isc.org <bind-users at lists.isc.org>
Subject: Re: DNSSEC algo rollover fails to delete old keys

This email originated from outside of TESLA

Do not click links or open attachments unless you recognize the sender and know the content is safe.

If you provide the output of `rndc dnssec -status` it might give a hint
why the keys are still published.

I suspect that BIND needs to be told that the DS has been withdrawn for
the parent zone (assuming you don't have parental-agents set up).

For future algorithm rollovers: You can just change from "algo8" to
"algo13", no need to have an intermittent "algo8-13" policy.

Best regards,

Matthijs

On 10/16/24 02:54, Arnold DECHAMPS wrote:
> Hello everyone,
>
> I made a algo rollover in DNSSEC from algo 8 to algo 13.
>
> Software version : 9.18.28-1~deb12u2-Debian
>
> My zone configuration refers to policies :
>
> ==========================================================================
>
> dnssec-policy "algo8" {
>      keys {
>          ksk lifetime unlimited algorithm rsasha256;
>          zsk lifetime 30d algorithm rsasha256;
>      };
>      max-zone-ttl 1d;
>      signatures-validity 14d;
>      signatures-refresh 7d;
> };
>
> dnssec-policy "algo13" {
>      keys {
>          ksk lifetime unlimited algorithm 13;
>          zsk lifetime 30d algorithm 13;
>      };
>      max-zone-ttl 1d;
>      signatures-validity 14d;
>      signatures-refresh 7d;
> };
>
> dnssec-policy "algo8-13" {
>      keys {
>          ksk lifetime unlimited algorithm rsasha256;    // Old Algo
>          zsk lifetime 30d algorithm rsasha256;        // Old Algo
>      ksk lifetime unlimited algorithm 13;        // New Algo
>          zsk lifetime 30d algorithm 13;            // New Algo
>      };
>      max-zone-ttl 1d;
>      signatures-validity 14d;
>      signatures-refresh 7d;
> };
>
> ==========================================================================
>
> The zone config looks like :
>
> ==========================================================================
>
> zone "somedomain.com"{
>      ...
>      inline-signing yes;
>          dnssec-policy "algo13";
>          key-directory "/etc/bind/keys";
> };
>
> ==========================================================================
>
>
> The initial idea was to switch the config of the domains that had to be
> rolled over to algo8-13 and temporarily have both keys in the zone
> waiting for the TTL of the DS records to expire. This was successful and
> algo 13 is now in use. I then switched to the algo13 policy and deleted
> the algo 8 keys of my keys directory.
>
> At this point, Bind sees that all the algo 8 keys are expired. It also
> see's that it can't find the files anymore (which prevents me from using
> dnssec-settime as far as I know).
>
> ==========================================================================
> dns_dnssec_keylistfromrdataset: error reading
> /etc/bind/keys/Ksomedomain.com.+008+16000.private: file not found
> dns_dnssec_findzonekeys2: error reading
> /etc/bind/keys/Ksomedomain.com.+008+16000.private: file not found
> ==========================================================================
>
> It stills publishes the DNSKEY in the signed zone. I would like to
> ideally correct this by forcing bind to discard the old keys. Is this
> possible to do? And if yes, how?
>
> Regards,
>
> Arnold
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20241016/b30a8458/attachment-0001.htm>