Re: [knot-dns-users] Old key is being used

Hi Libor, sorry for the late reply. We noticed another strange behaviour in our signer, which might be related to the previously stated issues. We signed a new zone, I'll refer to it as example.com in the examples, and it looks like the internal key management got mixed up in the process. E.g. the following CDS/CDNSKEY combination is published for the zone: $ dig cds example.com +short 32875 8 2 7E476D751F633B44C1D1ED3A78F986EDCD588E58415CFA10B1256FCB 10336E96 $ dig cdnskey example.com +multiline example.com. 0 IN CDNSKEY 257 3 8 ( AwEAAdKaHEdWflf.......bW5fiKHe6sQYUjaXj/YCQcn18= ) ; KSK; alg = RSASHA256 ; key id = 32875 So then as usual our process starts and picks up the new CDS/CDNSKEY records and attempts to upload them to the registry. Then the registry tells us, that the key is actually not yet published and therefor they won't accept our domain update. A quick dig request does in fact support the issue raised by the registry: $ dig dnskey example.com +multiline example.com. 7170 IN DNSKEY 257 3 8 ( AwEAAb1nUFjsy.....cueakqu/h4JoqiGRbH0gS77Ylp ) ; KSK; alg = RSASHA256 ; key id = 10051 example.com. 7170 IN DNSKEY 256 3 8 ( wEAAfTyql02Gh................CCp+DOxYYkKrYRdDEc ) ; ZSK; alg = RSASHA256 ; key id = 6123 Using the keymgr Tool we see the following entries for the zone: ~# keymgr -c /etc/knot/knot.conf example.com list 87472c54eb669c66353503caa0a386b1e95602de ksk=yes zsk=no tag=32875 algorithm=8 size=2048 public-only=no pre-active=0 publish=0 ready=1551269424 active=0 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 9304559cacf1f8a6e44a32591c5f6ba6a2ef002b ksk=yes zsk=no tag=10051 algorithm=8 size=2048 public-only=no pre-active=0 publish=1551269695 ready=0 active=1551269803 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 c2bd0743de6b4b07837e4936e983cae059adc928 ksk=no zsk=yes tag=06123 algorithm=8 size=1024 public-only=no pre-active=0 publish=1551269424 ready=0 active=1551269424 retire-active=0 retire=0 post-active=0 revoke=0 remove=0 Two KSK with Alg 8 have been created. Why 2 of them and why with Alg 8? We don't have Alg 8 in our policy anymore. Furthermore the key 32875 seems to be ready, but is not published in the zone, but it has been published as CDNSKEY. The one that is published in the zone has id 10051. There is something mixed up somehow. Our redacted knot.conf looks like this: server: listen: 192.168.1.123@53 user: knot:knot log: - target: /var/log/knot.log any: info control: listen: /var/run/knot/knot.sock remote: - id: local-resolver address: 192.168.1.2 submission: - id: resolver parent: local-resolver policy: - id: shared algorithm: RSASHA512 ksk-size: 2048 zsk-size: 1024 zsk-lifetime: 30d ksk-lifetime: 365d ksk-shared: true ksk-submission: resolver nsec3: true cds-cdnskey-publish: always - id: unsigned algorithm: RSASHA512 ksk-size: 2048 zsk-size: 1024 zsk-lifetime: 30d ksk-lifetime: 365d ksk-shared: true nsec3: true cds-cdnskey-publish: delete-dnssec key: - id: <keya> algorithm: hmac-sha256 secret: <secreta> - id: <keyb> algorithm: hmac-sha256 secret: <secretb> remote: - id: <remotea> address: <ip1> address: <ip2> key: <keyb> - id: <remoteb> address: <ip3> key: <keya> acl: - id: <remotea> address: <ip1> address: <ip2> key: <keyb> action: notify - id: <remoteb> address: <ip3> key: <keya> action: transfer template: - id: default storage: "/var/lib/knot/" semantic-checks: on global-module: mod-stats serial-policy: unixtime dnssec-signing: off zonefile-load: difference - id: signed storage: "/var/lib/knot/" dnssec-signing: on dnssec-policy: shared serial-policy: unixtime zonefile-load: difference - id: unsigned storage: "/var/lib/knot/" dnssec-signing: on dnssec-policy: unsigned serial-policy: unixtime zonefile-load: difference zone: - domain: example.com. template: signed master: [<remotea>] notify: [<remoteb>] acl: [<remotea>, <remoteb>] acl: [<remotea>, <remoteb>] We have a few thousand zones set up in this way, with only a handful of them being signed yet. We know that the algorithm RSASHA512 should not be used, but we wanted to complete all key rollovers, before attempting another key rollover to ECDSAP256SHA256. Thanks a lot, Thomas On 20.01.21 21:41, libor.peltan wrote: