multi-signer generated an invalid DNSKEY

OS: Rocky Linux release 8.10 (Green Obsidian)

Knot Version: knot-3.3.4/3.4.0

Two knot instances are set up on the two hosts AB as multi-signer

Host A knot uses HSM、 algorithm 13、 and the key is automatically rotated.

Host B kot uses softhsm, algorithm 8, key manual rotation.

Symptom: Host A knot's signature file has multiple ZSK/KSK (there is no wheel rotation period), dig command is also

Host A(xxx.xxx.xxx.1)

remote:
  - id: signer2
    address: [ xxx.xxx.xxx.2@5318 ]
remotes:
  - id: signers
    remote: [ signer2 ]
acl:
  - id: update_from_signers
    remote: [ signer2 ]
    action: [ query, update ]
dnskey-sync:
    - id: sync
      remote: [ signers ]
keystore:  
  - id: "tass"
    backend: pkcs11
    config: "pkcs11:token=HSM;pin-value=xxxxxxx /home/gtld/workspace/tass/libTassPkcs11.so"
policy:  
  - id: auto
    manual: off
    keystore: tass
    algorithm: ecdsap256sha256
    zsk-size: 256
    ksk-lifetime: 3650d
    zsk-lifetime: 90d
    delete-delay: 200d
    dnskey-management: incremental
    cds-cdnskey-publish: none
    dnskey-sync: sync

Host B(xxx.xxx.xxx.2)

remote:
  - id: signer1
    address: [ xxx.xxx.xxx.1@5318 ]
remotes:
  - id: signers
    remote: [ signer1 ]
acl:
  - id: update_from_signers
    remote: [ signer1 ]
    action: [ query, update ]
dnskey-sync:
    - id: sync
      remote: [ signers ]

keystore: 
  - id: "softhsm"
    backend: pkcs11
    config: "pkcs11:token=softhsm;pin-value=xxxx /home/gtld/softhsm/lib/softhsm/libsofthsm2.so"
policy:  
  - id: auto
    manual: on
    keystore: softhsm
    signing-threads: 16
    algorithm: rsasha256
    ksk-lifetime: 3650d
    zsk-lifetime: 90d
    delete-delay: 200d
    dnskey-management: incremental
    cds-cdnskey-publish: always
    dnskey-sync: sync

dig @xxx.xxx.xxx.1 -p5318 xn--ses554g dnskey +mul|grep id

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 668
                                ) ; ZSK; alg = RSASHA256 ; key id = 51181
                                ) ; ZSK; alg = ECDSAP256SHA256 ; key id = 41388
                                ) ; ZSK; alg = ECDSAP256SHA256 ; key id = 44534
                                ) ; KSK; alg = RSASHA256 ; key id = 34994
                                ) ; KSK; alg = ECDSAP256SHA256 ; key id = 57714
                                ) ; KSK; alg = ECDSAP256SHA256 ; key id = 13002

grep -E '41388|44534|57714|13002' ../log/knot.log -w

2024-09-12T10:15:30+0800 info: [xn--ses554g.] DNSSEC, key, tag 13002, algorithm ECDSAP256SHA256, KSK, public, ready, active+
2024-09-12T10:15:30+0800 info: [xn--ses554g.] DNSSEC, key, tag 44534, algorithm ECDSAP256SHA256, public, active
2024-09-12T10:17:46+0800 info: [xn--ses554g.] DNSSEC, key, tag 44534, algorithm ECDSAP256SHA256, public, active
2024-09-12T10:17:46+0800 info: [xn--ses554g.] DNSSEC, key, tag 13002, algorithm ECDSAP256SHA256, KSK, public, ready, active+

/usr/local/knot/sbin/keymgr -c knot.conf xn--ses554g list

03bcf3c859e6bea4bcecb816be03544df9b05cad 44534 ZSK ECDSAP256SHA256 created=1726107324 publish=1726107324 active=1726107324
fcb322f0e3282ce661210eabd492e54749686cff 13002 KSK ECDSAP256SHA256 created=1726107324 publish=1726107324 ready=1726107324

There's no record of the abnormal dnskey in the knot log

I have a lot of zones, and I find that not all of them generate abnormal Dnskeys, but the longer you run, the more zones have problems

I tried two versions of the knot and both had this problem. I'm not sure if it's the knot or the encryption machine (it doesn't feel like it)

changed the description

Hi yuchunyun,

first of all, any attempt to run multi-signer with different algorithms leads to non-compliance with RFC 4035. Therefore, I'd recommend against doing so. If the goal of the multi-signer setup is signer migration, I'd recommend to migrate the signer first with the old algorithm, any only after switching to the new signer, performing a correct algorithm roll-over.

From the data you provided, it is unclear where did the DNSKEYs with key-tags 57714 and 41388 come from. They might have been loaded from zone file or received as a DDNS on any of the signers. Are you able to back track the zone journal and/or logs to find out when did they first appear and where, and what was going on at that moment? In any case, please note that their continued presence is a consequence of the setting dnskey-management: incremental (which is cruical for any multi-signer setups), which tells Knot to handle DNSKEY RRSet incrementally, removing only those DNSKEYs whose removal is somehow explicitly requested.

Thank you for reminding me that I really didn't notice about RFC 4035. Yes, my ultimate goal is to replace the encryption machine and the signature algorithm, so it looks like I need to do this in two steps.

I am very sure that my zone files are all transferred from upstream, and it has no DNSSEC, only have two signers. I am very confused about how these two DNSKEYs are generated. Strangely, I can't see the key rotation and any logs about these two ids from the knot.log of the signer. I don't know if there's another way to trace it

I think I may have found the reason I had initialized the knot instance A few times on host A (deleting the keys/mdb and zone files), but the old DNSKEY had been synched to Host B and stored in its zonefile. After host A uses the new DNSKEY signature, host B synchronizes the old DNSKEY data to host A. So there's no information about these DNSKEYs in the log

I wonder if the knot can print more log information about DNSKEY sync, or maintain the synchronized DNSKEY information (prevent reverse synchronization).

...so the "old A" behave like a third signer in this setup :) Improved logging is a good idea, thank you, let me try it.

We have added some extra logging for DNSKEY synchronization in !1715 (merged) Hopefully, this will help. It will be released in 3.4.1.

closed