VS: Change DNSSEC algorithm and switch to use KASP

Matthijs Mekking matthijs at isc.org
Tue Apr 28 06:43:34 UTC 2020


Hi,

If you want to switch to KASP with the a different algorithm, you should 
be able to use BIND 9.16.2 and just reconfigure your zone to use 
"dnssec-policy".  The existing keys will be removed in a timely manner, 
while named creates new keys with the new algorithm.

Make sure you will submit the DS to your parent once the new CDS/CDNSKEY 
record is published in your zone.

Best regards,

Matthijs

On 25-04-2020 22:28, Jukka Pakkanen wrote:
> I just did the same operation in our BIND servers, converted all DNSSEC enabled zones with different algorithms to KASP/dnssec-policy and ecdsa256/13.
> 
> All I did was replaced the two lines in named.conf:
> 
>      inline-signing yes;
>      auto-dnssec maintain;
> 
> to
> 
>     dnssec-policy "ecdsa256";
> 
> And of course created the policy there too.
> 
> If the algorithm in the zone was changed (previously something else than "13"), updated the DS record at the registrar as well.
> 
> Worked out smoothly, ok there was a brief moment before the new DS was published and zone secured again, but did this at night time, at the morning everything was perfect, and now all zones using that policy.
> 
> Jukka
> 
> 
> -----Alkuperäinen viesti-----
> Lähettäjä: bind-users <bind-users-bounces at lists.isc.org> Puolesta Matthias Fechner
> Lähetetty: 25. huhtikuuta 2020 10:08
> Vastaanottaja: bind-users at lists.isc.org
> Aihe: Change DNSSEC algorithm and switch to use KASP
> 
> Dear all,
> 
> I followed now the series here (again, thanks a lot to make this public!):
> https://www.youtube.com/watch?v=MheHMWCOTvE&list=PLUwyH0o3uuICgnbQj_lQajRI_CzewZr7q
> 
> Just now I only sign one domain which is using the "auto-dnssec maintain;".
> What I understood from the series is that KASP does not support switching from "auto-dnssec maintain" to KASP, yet.
> 
> As my single domain is using RSASHA256 and I want to use one algorithm
> (ECDSA256)  for each domain I maintain in my DNS servers (to would like to have a clean start with KASP).
> I just wanted to make sure I do not break this single domain
> (fechner.net) which is already signed.
> I cannot remove DNSSEC before the DS has disappeared on the parent.
> 
> What I understood so far is using the following procedure (to disable DNSSEC for this single specific domain):
> - ask the parent zone to remove the DS (as long as the DS exists in the parent zone I must not remove DNSSEC as that would break the zone)
> - after the DS disappeared in the parent zone, wait for at least the TTL of the DS (86400) + maybe one day (safety)
> - now my zone does not require to have DNSSEC and I can remove DNSSEC
> - instruct bind to delete the key using dnssec-settime to remove the key (dnssec-settime -I +1d -D +2d keyfile)
> - wait 2 days
> - check no RRSIGS are existing for the domain
> - wait for one day (TTL) + 1 say (safety) = at least 2 days
> - now start to use KASP and let it create keys and sign your zone using
> ecdsa256 (is this a recommended algo for using DNSSEC?)
> - wait till CDS and CDNSKEY appears in the zone (bind ensures here the TTLs match, so it will not add the CDS before required time is passed)
> - ask parent to add the DS to their zone
> - the moment the DS is added on parent, DNSSEC is enforced
> 
> If I do not ask the parent to add the DS key, I can keep DNSSEC for the zones, but it will not be enforced or?
> (this does not work if the registra would import the DS because CDS and CDNSKEY keys are existing, so be carefull here)
> 
> I'm talking here about zone fechner.net.
> 
> The TTL on the parent seems to be 86400:
> dig +dnssec +multi -t DS fechner.net. @A.GTLD-SERVERS.NET ...
> fechner.net.            86400 IN DS 64539 10 2 (
>                                  12860767104BEE7B250F03B5D03425BC978F65CB426E
>                                  EDC9C9B541AFB5D52D8D ) fechner.net.            86400 IN DS 64539 10 1 (
>                                  81EF72A9B9D92A9FD4F50856D1371DA05F5ACC27 ) ...
> 
> The TTL in my zone is also 86400, so I used this for all waiting times.
> 
> Thanks a lot for any comments!
> 
> Gruß
> Matthias
> 


More information about the bind-users mailing list