Questions about automatic KSK and using an additional stand-by KSK

Matthijs Mekking matthijs at isc.org
Mon Feb 24 08:47:39 UTC 2025


Hi Bernd,

Non-signing keys (for example a stand-by key), is a bit tricky in 
dnssec-policy and not fully supported.

In 9.18, I would suggest to disable inline-signing and just add the 
DNSKEY record to the zone. Don't put the key files for the stand-by key 
in the 'key-directory', this should only hold signing keys.

In 9.20 this is fixed and you should be able to add the DNSKEY record to 
the zone, even with inline-signing enabled.

Also note that dnssec-policy does not support RFC 5011 (yet).

Best regards,

Matthijs


On 21-02-2025 12:32, Bernd Naumann wrote:
> I've followed the ARM and the DNSSEC Guide, as well as some ISC KB blog
> posts.
> 
> What I got working on BIND 9.18.33:
> * adding a dnsssec-policy
> * adding a zone using that dnssec-policy
> 	- setting only SOA, NS, and the AAAA for NS for a minimal zone
> * reload zone
> 
> I got an KSK and ZSK; the zone got signed; I added the KSK to
> `trust-anchors` as an `initial-key`, and saw that the key got /managed/.
> 
> So far so good.
> 
> ```
> dnssec-policy "dn42-ec" {
>      keys {
>          ksk lifetime P1Y algorithm ecdsa256;
>          zsk lifetime P60D algorithm ecdsa256;
>      };
>      purge-keys 0;
> };
> 
> zone "example.dn42" {
>          type primary;
>          file "/etc/bind/db.dn42.example";
>          dnssec-policy dn42-ec;
>          inline-signing yes;
>          allow-transfer {
>                  fd00::/8;
>          };
> };
> ```
> 
> ```
> # cat /etc/bind/keys/Kexample.dn42.+013+03829.key
> ; This is a key-signing key, keyid 3829, for example.dn42.
> ; Created: 20250220195943 (Thu Feb 20 19:59:43 2025)
> ; Publish: 20250220195943 (Thu Feb 20 19:59:43 2025)
> ; Activate: 20250220195943 (Thu Feb 20 19:59:43 2025)
> ; Inactive: 20260220195943 (Fri Feb 20 19:59:43 2026)
> ; Delete: 20260221215943 (Sat Feb 21 21:59:43 2026)
> ; SyncPublish: 20250221210443 (Fri Feb 21 21:04:43 2025)
> example.dn42. 3600 IN DNSKEY 257 3 13
> pMlQUzpKNh2rgEh+DsazO8AiOHKFSpIvUltNPufKR26CugUU1p/1E8fi
> atOqnOKIqUqrW+EJF/+RrgDPxfhW/A==
> 
> # cat /etc/bind/keys/Kexample.dn42.+013+41655.key
> ; This is a zone-signing key, keyid 41655, for example.dn42.
> ; Created: 20250220195943 (Thu Feb 20 19:59:43 2025)
> ; Publish: 20250220195943 (Thu Feb 20 19:59:43 2025)
> ; Activate: 20250220195943 (Thu Feb 20 19:59:43 2025)
> ; Inactive: 20250421195943 (Mon Apr 21 19:59:43 2025)
> ; Delete: 20250501210443 (Thu May  1 21:04:43 2025)
> example.dn42. 3600 IN DNSKEY 256 3 13
> oRwtJvxmISF4H9eMXkbqgL87muMvwP/D3v+dzki0GoYhl3d7OD03Jaeg
> ykM+Qra0swAGHNfpprwsmjiOL7J00Q==
> ```
> 
> 
> I then generated an stand-by key `dnssec-keygen -G` and included it to
> the zone.
> 
> I tried sync, freeze, /update/, reload, thaw; and
> I tried to `update add` the DNSKEY Record.
> 
> 
> But, my issue is now: **I don't see the second KSK in the zone.**
> 
> I went through the manual generation and sign process and IIRC adding a
> second KSK and seeing afterwards 2x KSK and 1x ZKS wasn't an issue.
> 
> What mistakes I do when trying to add a stand-by KSK to a auto-managed
> zone? Or do I need to stick with the manual update and signing process?
> 
> (In the end I want to have the second KSK known to resolver so they can
> manage (rfc 5011) that key for later revocation and roll-over events.)
> 
> Thanks.
> Bernd
> 
> 


More information about the bind-users mailing list