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 <[email protected] > 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 > > [email protected] > > https://lists.opendnssec.org/mailman/listinfo/opendnssec-user > > > > _______________________________________________ > Opendnssec-user mailing list > [email protected] > https://lists.opendnssec.org/mailman/listinfo/opendnssec-user >
kasp.xml.gz
Description: GNU Zip compressed data
_______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
