Signer mixed up CKA_ID, key tag, public key

Hello,

Another unpredictable problem I fear. Or maybe it's the same?

There is a one-time work-around: ods-signer stop ; drop zone-related files in /var/opendnssec/tmp ; ods-signer start

We received errors about the signature on a zone's SOA, and found its AAAA on localhost wrong as well, but its A was working. It would seem that the Signer is in a confused state about what key to use for new signatures.

The Enforcer is not confused. It advised us to use key fff5d48a5902d8feff99b6cf4456bb0c which has key tag 8335. We downloaded the modulus from the HSM, put it in base64 format and used ldns-key2ds to determine that this is the right key tag. The Enfircer coupled this key tag to the CKA_ID in the ods-enforcer key list, and it was also the active key. This, and the resolution with a restarted Signer without tmp heritage shows us that the problem is not Enforcer-related.

Our zone advertised a SOA record signed with key 30444, also occurring in the /var/opendnssec/tmp/ip4afrika.nl.backup file:

;;Key: locator fff5d48a5902d8feff99b6cf4456bb0c algorithm 8 flags 256 publish 1 ksk 0 zsk 1
ip4afrika.nl. 3600 IN DNSKEY 256 3 8 AwEAAcgow5V6X3UaNU5EL6WcxhuKkg6tan/T+zEudvTzyI5krqulmLjnwMtscV7hZTlEWfFHIa0C9IqQw59C7IgrlYHOkVBiCav3QbC6JvYQSYKklQK7pWW6H2B8lEbAudKGNNMChDHPIKEw+9ZH0k9B4M6qeCMQEhP/IExCOutGwbpP ;

{id = 30444 (zsk), size = 1024b}
;;Keydone

Passing that into ldns-key2ds results in the claimed key tag 30444:

[root@whitfield vanrein]# cat /tmp/k3
ip4afrika.nl. 3600 IN DNSKEY 256 3 8 AwEAAcgow5V6X3UaNU5EL6WcxhuKkg6tan/T+zEudvTzyI5krqulmLjnwMtscV7hZTlEWfFHIa0C9IqQw59C7IgrlYHOkVBiCav3QbC6JvYQSYKklQK7pWW6H2B8lEbAudKGNNMChDHPIKEw+9ZH0k9B4M6qeCMQEhP/IExCOutGwbpP ;{id = 30444 (zsk), size = 1024b}

[root@whitfield vanrein]# ldns-key2ds -f -n -2 /tmp/k3
ip4afrika.nl. 3600 IN DS 30444 8 2 0f3de774cd3977328cd7c8c4b101cbadb446a598829169d57ced3e38ae2dda44

However note that this is not the key pointed to by the label fff5d48a5902d8feff99b6cf4456bb0c printed above it. We think this could be a sign or the cause of the confusion inside the Signer.

ip4afrika.nl. 3600 IN SOA ns1.surfnet.nl. hostmaster.surfnet.nl. 2013090101 20800 3600 604800 3600
ip4afrika.nl. 3600 IN RRSIG SOA 8 2 3600 20130915052459 20130901021418 30444 ip4afrika.nl. N0R9ZVxClOCUm4gXtLKFPd3h0HpwNaM6vbZcUp5u/emxiwVPo0XeCTta DdcYLKIR9b+rtOQdH5kIOlqweJgIZq5I8bAGEusg8yv/ZWY3gOpAqMD9 B4UfmJLxaawesz0VTU+8beUhHxLJbfG8lJz5xRAw6Re6xm19I5IQ1fYO L/k=

ip4afrika.nl. 2953 IN DNSKEY 256 3 8 AwEAAcgow5V6X3UaNU5EL6WcxhuKkg6tan/T+zEudvTzyI5krqulmLjn wMtscV7hZTlEWfFHIa0C9IqQw59C7IgrlYHOkVBiCav3QbC6JvYQSYKk lQK7pWW6H2B8lEbAudKGNNMChDHPIKEw+9ZH0k9B4M6qeCMQEhP/IExC OutGwbpP
ip4afrika.nl. 2953 IN DNSKEY 257 3 8 AwEAAcnuNGgoSq6FNdQY7c72tH1yvOPhtkGmE5DYzV46muLgrOphWJfT CMKBqwAFsC7fWCeoT+HVH1+m42o3x19aoYLHvikPeGJ8rMdidKBbW35r VrV0i+wzIaXXjaWYFD07I+R6/1mesKbQDq5+RBGGQ1RxBJoLF3E4t4JJ 9Ei/qZ1GMATFfCY3TXio8XuJFKKbiDJ0P7wSYs0PAvOeorkJQq7/SRO5 gdCdiEuo+6KamKp8JyqxECKtHr2vgK7XghoRX3sMSAHMyjVn6VvkKd4Q b5lN7M0Sxxw4uXU66QSQ7wWQERh7aWXNkOHJYgRjPN8vEVJV1GfV2Qbc XobPCltx/90=
ip4afrika.nl. 2953 IN DNSKEY 256 3 8 AwEAAafyWcGUjxoi8X7i5VcmvUQIpgIvsXXG6fGPm7gheDUponqVnzWQ a180sX73pF7PFkK17Y2A6rWcC52fK+vxc5sMT2e/BcGWTUZdr60aiJWg WZJdrJjAGWV86MQC48jKoE1UNdY8pzhgHaZ/3cRbZd+3RRDiuiEA0/0O WVZCTZ3x
ip4afrika.nl. 2953 IN DNSKEY 256 3 8 AwEAAajvJtgoArZYWi9Xhl1UJEF60IilJ42/PSnQWqjkxbuFHebcO1fx IczeglXVWotVid5+G5wq+2isLE68Ycq6DVGLLg2oEBorfi2I465Yaocf 0vk0siADqefmFmBk5wo/TlazUe8yXvS82nNqw3fZjb7RVYKUoI679iCm XHYVxR9L

Digging up the zone file for this zone, we did find one line that thinks it holds key tag 8335 though, but which really is 30444 as shown with ldns-key2ds:

root@whitfield vanrein]# cat > /tmp/k-saying-8335
ip4afrika.nl. 3600 IN DNSKEY 256 3 8 AwEAAcgow5V6X3UaNU5EL6WcxhuKkg6tan/T+zEudvTzyI5krqulmLjnwMtscV7hZTlEWfFHIa0C9IqQw59C7IgrlYHOkVBiCav3QbC6JvYQSYKklQK7pWW6H2B8lEbAudKGNNMChDHPIKEw+9ZH0k9B4M6qeCMQEhP/IExCOutGwbpP ;

{id = 8335 (zsk), size = 1024b}

^D
[root@whitfield vanrein]# ldns-key2ds -f -n -1 /tmp/k-saying-8335
ip4afrika.nl. 3600 IN DS 30444 8 1 79a7e19c2a19f332fb7805477bbecb8a680b027b

Manual recalculations in Python recovered that the actual key used to sign the SOA and other failing records is the 8335 key. Note that the pattern of a correct signature is simple to recognise in hex, as it starts with 01fffff... – interestingly, we did not find this key in the DNSKEY output for the zone, but we found the 30444 key with this tag attached.

Looks to me like a mixup in the internal housekeeping of the Signer. Not sure why it is so rare, but we thought we'd get to the bottom of it, and until then, continue to monitor our zones.