[Opendnssec-user] zone signed with wrong key

[Emil Natan]

Hello,

opendnssec version 1.4.13.

The zonefile is signed with 51915 ZSK when I'm expecting it to be signed
with 37063 ZSK. The DNSKEY RRset contains all four keys and is correctly
signed with both KSKs. I force signing with ods-signer sign zone with the
same result.

# ods-ksmutil key list -z example.com -v
...
Keys:
Zone: Keytype: State: Date of next
transition (to): Size: Algorithm: CKA_ID:
Repository: Keytag:
example.com KSK active 2017-03-29
15:38:36 (retire) 2048 8 379855eb637390420bb659c63e34875a
Keyper 31082
example.com ZSK retire 2017-07-30
23:59:30 (dead) 2048 8 898c304545fcf1bbd3b4f4dee01de431
Keyper 51915
example.com KSK ready waiting for
ds-seen (active) 2048 8 41cc87e43330a139c10daec84c926af6
Keyper 35999
example.com ZSK active 2017-10-30
21:59:30 (retire) 2048 8 569cfa7acc4e45518ba9c6bb64660b6d
Keyper 37063

from signconf file for the zone:

<Keys>
<TTL>PT3600S</TTL>
<Key>
<Flags>257</Flags>
<Algorithm>8</Algorithm>

<Locator>379855eb637390420bb659c63e34875a</Locator>
<KSK />
<Publish />
</Key>

<Key>
<Flags>257</Flags>
<Algorithm>8</Algorithm>

<Locator>41cc87e43330a139c10daec84c926af6</Locator>
<KSK />
<Publish />
</Key>

<Key>
<Flags>256</Flags>
<Algorithm>8</Algorithm>

<Locator>898c304545fcf1bbd3b4f4dee01de431</Locator>
<Publish />
</Key>

<Key>
<Flags>256</Flags>
<Algorithm>8</Algorithm>

<Locator>569cfa7acc4e45518ba9c6bb64660b6d</Locator>
<ZSK />
<Publish />
</Key>

</Keys>

This is from the backup2 file which is recent:
;;Key: locator 379855eb637390420bb659c63e34875a algorithm 8 flags 257
publish 1 ksk 1 zsk 0 rfc5011 0
;;Key: locator 41cc87e43330a139c10daec84c926af6 algorithm 8 flags 257
publish 1 ksk 1 zsk 0 rfc5011 0
;;Key: locator 898c304545fcf1bbd3b4f4dee01de431 algorithm 8 flags 256
publish 1 ksk 0 zsk 1 rfc5011 0
;;Key: locator 569cfa7acc4e45518ba9c6bb64660b6d algorithm 8 flags 256
publish 1 ksk 0 zsk 0 rfc5011 0

And here are the signatures created:
example.com. 86400 IN RRSIG SOA 8 2 86400 20170818133611
20170718123611 51915 example.com.
IFHFZF7DTgwPATmWw3tLyEAYUdwGMhH9BCON4uGr7invMz64NRNLD142Yz...
example.com. 86400 IN RRSIG NS 8 2 86400 20170818133611
20170718123611 51915 example.com.
K37AntYRr29Ad9H/EvlDsjwFHhLLnj4TBq2x93flDa4laMhyXdgKAQz0t4SnBp49...

Thank you in advance.
Emil

[Berry A.W. van Halderen]

Post by Emil Natan
opendnssec version 1.4.13.

Dear Emil,

From the output you've given, it looks like you have a policy where the
signatures are valid for a month and the signatures are fresh. Hence
they would be re-used by the signer, since the signatures are still
valid for quite a while, the signer will keep them until they are near
expiration (exact time depending on your policy).

The "key list" indicates that according to the enforcer, all signatures
are gone by 2017-07-30 23:59, and the ZSK would be dead.

Slowly you could expect signatures to be disappearing. If you however
believe according to your policy there should be already signatures that
would have gone, it is also possible that your signer was not running
when the enforcer would inform the signer of a new signconf file.

It this is the case you can issue a "ods-signer update example.com...",
which would have been executed by the enforcer to inform the signer.

\Berry

Post by Emil Natan
The zonefile is signed with 51915 ZSK when I'm expecting it to be signed
with 37063 ZSK. The DNSKEY RRset contains all four keys and is correctly
signed with both KSKs. I force signing with ods-signer sign zone with
the same result.
# ods-ksmutil key list -z example.com <http://example.com> -v
...
Zone: Keytype: State: Date of next
example.com <http://example.com> KSK
active 2017-03-29 15:38:36 (retire) 2048 8
379855eb637390420bb659c63e34875a Keyper 31082
example.com <http://example.com> ZSK
retire 2017-07-30 23:59:30 (dead) 2048 8
898c304545fcf1bbd3b4f4dee01de431 Keyper 51915
example.com <http://example.com> KSK
ready waiting for ds-seen (active) 2048 8
41cc87e43330a139c10daec84c926af6 Keyper 35999
example.com <http://example.com> ZSK
active 2017-10-30 21:59:30 (retire) 2048 8
569cfa7acc4e45518ba9c6bb64660b6d Keyper 37063
<Keys>
<TTL>PT3600S</TTL>
<Key>
<Flags>257</Flags>
<Algorithm>8</Algorithm>
<Locator>379855eb637390420bb659c63e34875a</Locator>
<KSK />
<Publish />
</Key>
<Key>
<Flags>257</Flags>
<Algorithm>8</Algorithm>
<Locator>41cc87e43330a139c10daec84c926af6</Locator>
<KSK />
<Publish />
</Key>
<Key>
<Flags>256</Flags>
<Algorithm>8</Algorithm>
<Locator>898c304545fcf1bbd3b4f4dee01de431</Locator>
<Publish />
</Key>
<Key>
<Flags>256</Flags>
<Algorithm>8</Algorithm>
<Locator>569cfa7acc4e45518ba9c6bb64660b6d</Locator>
<ZSK />
<Publish />
</Key>
</Keys>
;;Key: locator 379855eb637390420bb659c63e34875a algorithm 8 flags 257
publish 1 ksk 1 zsk 0 rfc5011 0
;;Key: locator 41cc87e43330a139c10daec84c926af6 algorithm 8 flags 257
publish 1 ksk 1 zsk 0 rfc5011 0
;;Key: locator 898c304545fcf1bbd3b4f4dee01de431 algorithm 8 flags 256
publish 1 ksk 0 zsk 1 rfc5011 0
;;Key: locator 569cfa7acc4e45518ba9c6bb64660b6d algorithm 8 flags 256
publish 1 ksk 0 zsk 0 rfc5011 0
example.com <http://example.com>. 86400 IN RRSIG SOA 8 2 86400
20170818133611 20170718123611 51915 example.com <http://example.com>.
IFHFZF7DTgwPATmWw3tLyEAYUdwGMhH9BCON4uGr7invMz64NRNLD142Yz...
example.com <http://example.com>. 86400 IN RRSIG NS 8 2 86400
20170818133611 20170718123611 51915 example.com <http://example.com>.
K37AntYRr29Ad9H/EvlDsjwFHhLLnj4TBq2x93flDa4laMhyXdgKAQz0t4SnBp49...
Thank you in advance.
Emil
_______________________________________________
Opendnssec-user mailing list
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user

[Emil Natan]

Hi Berry,

Thank you very much for your response.

I do not think it's a matter of preserving signatures. First (and sorry for
not bringing up this earlier) the policy in use has refresh interval of
zero (<Refresh>PT0S</Refresh>) so all signatures should be generated every
time the signer runs. Second, the signatures are always generated and I see
the inception and expiration timestamps reflecting on that. Here is how the
signature looks when I forced resign today:

example.com. 86400 IN RRSIG SOA 8 2 86400 20170819061448
20170719051448 51915 example.com.
qj0MmG/W4XzY2TxePRHC7xCcqG2adU00FosgnWIkAFo9MnQkuzn5aXbU2wlcKQ16DhIpnGVmMQ5gMh9hxy....

Still ZSK with keytag 51915 is used instead of 37063.

"ods-signer update" helped though. After running it I see the zone signed
with ZSK with keytag 37063. I do not know how it is different from
restarting the signer which is the first thing I tried yesterday.

Thank you for you help.

Emil

Post by Berry A.W. van Halderen

Post by Emil Natan
opendnssec version 1.4.13.

Dear Emil,
From the output you've given, it looks like you have a policy where the
signatures are valid for a month and the signatures are fresh. Hence
they would be re-used by the signer, since the signatures are still
valid for quite a while, the signer will keep them until they are near
expiration (exact time depending on your policy).
The "key list" indicates that according to the enforcer, all signatures
are gone by 2017-07-30 23:59, and the ZSK would be dead.
Slowly you could expect signatures to be disappearing. If you however
believe according to your policy there should be already signatures that
would have gone, it is also possible that your signer was not running
when the enforcer would inform the signer of a new signconf file.
It this is the case you can issue a "ods-signer update example.com...",
which would have been executed by the enforcer to inform the signer.
\Berry

Post by Emil Natan
The zonefile is signed with 51915 ZSK when I'm expecting it to be signed
with 37063 ZSK. The DNSKEY RRset contains all four keys and is correctly
signed with both KSKs. I force signing with ods-signer sign zone with
the same result.
# ods-ksmutil key list -z example.com <http://example.com> -v
...
Zone: Keytype: State: Date of next
example.com <http://example.com> KSK
active 2017-03-29 15:38:36 (retire) 2048 8
379855eb637390420bb659c63e34875a Keyper

31082

Post by Emil Natan
example.com <http://example.com> ZSK
retire 2017-07-30 23:59:30 (dead) 2048 8
898c304545fcf1bbd3b4f4dee01de431 Keyper

51915

Post by Emil Natan
example.com <http://example.com> KSK
ready waiting for ds-seen (active) 2048 8
41cc87e43330a139c10daec84c926af6 Keyper

35999

Post by Emil Natan
example.com <http://example.com> ZSK
active 2017-10-30 21:59:30 (retire) 2048 8
569cfa7acc4e45518ba9c6bb64660b6d Keyper

37063

Post by Emil Natan
<Keys>
<TTL>PT3600S</TTL>
<Key>
<Flags>257</Flags>
<Algorithm>8</Algorithm>
<Locator>379855eb637390420bb659c63e34875a</Locator>
<KSK />
<Publish />
</Key>
<Key>
<Flags>257</Flags>
<Algorithm>8</Algorithm>
<Locator>41cc87e43330a139c10daec84c926af6</Locator>
<KSK />
<Publish />
</Key>
<Key>
<Flags>256</Flags>
<Algorithm>8</Algorithm>
<Locator>898c304545fcf1bbd3b4f4dee01de431</Locator>
<Publish />
</Key>
<Key>
<Flags>256</Flags>
<Algorithm>8</Algorithm>
<Locator>569cfa7acc4e45518ba9c6bb64660b6d</Locator>
<ZSK />
<Publish />
</Key>
</Keys>
;;Key: locator 379855eb637390420bb659c63e34875a algorithm 8 flags 257
publish 1 ksk 1 zsk 0 rfc5011 0
;;Key: locator 41cc87e43330a139c10daec84c926af6 algorithm 8 flags 257
publish 1 ksk 1 zsk 0 rfc5011 0
;;Key: locator 898c304545fcf1bbd3b4f4dee01de431 algorithm 8 flags 256
publish 1 ksk 0 zsk 1 rfc5011 0
;;Key: locator 569cfa7acc4e45518ba9c6bb64660b6d algorithm 8 flags 256
publish 1 ksk 0 zsk 0 rfc5011 0
example.com <http://example.com>. 86400 IN RRSIG SOA 8 2 86400
20170818133611 20170718123611 51915 example.com <http://example.com>.
IFHFZF7DTgwPATmWw3tLyEAYUdwGMhH9BCON4uGr7invMz64NRNLD142Yz...
example.com <http://example.com>. 86400 IN RRSIG NS 8 2 86400
20170818133611 20170718123611 51915 example.com <http://example.com>.
K37AntYRr29Ad9H/EvlDsjwFHhLLnj4TBq2x93flDa4laMhyXdgKAQz0t4SnBp49...
Thank you in advance.
Emil
_______________________________________________
Opendnssec-user mailing list
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user

_______________________________________________
Opendnssec-user mailing list
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user

[Berry A.W. van Halderen]

Post by Emil Natan
Hi Berry,
Thank you very much for your response.
I do not think it's a matter of preserving signatures. First (and sorry
for not bringing up this earlier) the policy in use has refresh interval
of zero (<Refresh>PT0S</Refresh>) so all signatures should be generated
every time the signer runs. Second, the signatures are always generated
and I see the inception and expiration timestamps reflecting on that.
example.com <http://example.com>. 86400 IN RRSIG SOA 8 2 86400
20170819061448 20170719051448 51915 example.com <http://example.com>.
qj0MmG/W4XzY2TxePRHC7xCcqG2adU00FosgnWIkAFo9MnQkuzn5aXbU2wlcKQ16DhIpnGVmMQ5gMh9hxy....
Still ZSK with keytag 51915 is used instead of 37063.
"ods-signer update" helped though. After running it I see the zone
signed with ZSK with keytag 37063. I do not know how it is different
from restarting the signer which is the first thing I tried yesterday.

A, that quite explains it. Indeed the signer wasn't running at the time
the enforcer issued an "ods-signer update" command. The enforcer has no
retry mechanism to do this, and you have the assumption that the signer
reads the signconf files during startup. However this is not the case,
it uses these values from the backup files. Hence the signer is never
really informed of a new signconf.

Your assumption isn't really strange, and I could imagine you want to,
but there are also some arguments for only reading in these files
upon explicit request. So these are areas in which future releases may
differ, but the 1.4 will not change this behaviour.

With kind regards,
Berry van Halderen