[Opendnssec-user] zone signed with wrong key
Emil Natan
shlyoko at gmail.com
Wed Jul 19 06:38:19 UTC 2017
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
On Tue, Jul 18, 2017 at 7:52 PM, Berry A.W. van Halderen <berry at nlnetlabs.nl
> wrote:
> On 07/18/2017 04:57 PM, Emil Natan wrote:
> > 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
>
> > 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
> > ...
> > Keys:
> > Zone: Keytype: State: Date of next
> > transition (to): Size: Algorithm: CKA_ID:
> > Repository: Keytag:
> > 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
> >
> > 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 <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
> > Opendnssec-user at lists.opendnssec.org
> > https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
> >
>
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20170719/4935e54e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kasp.xml.gz
Type: application/x-gzip
Size: 681 bytes
Desc: not available
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20170719/4935e54e/attachment.bin>
More information about the Opendnssec-user
mailing list