[Opendnssec-user] End-of-life OpenDNSSEC 1.3 on 2017-07-11
Wytze van der Raay
wytze at deboca.net
Sat Jul 16 15:29:56 UTC 2016
On 07/15/2016 01:46 PM, Yuri Schaeffer wrote:
>> However, then the 2.0 migration instructions point me to
>> enforcer/utils/1.4-2.0_db_convert/README.md. This instructs me
>> to execute the convert_sqlite script. The script starts off with
>> a reference SCHEMA=../../src/db/schema.sqlite, but that schema.sqlite
>> file does not exist anywhere in the src distro.
>> Should it? Or should it be generated somehow?
> I just checked the release tarball and indeed it isn't there! Quick
> workaround check out the complete source from github.
Thanks for the quick response and all follow-up actions, including
the new release. I managed to complete the upgrade (from 1.4.10 now)
to 2.0.0-1, but things were not as smooth as I had hoped for.
1. The MIGRATION file in the 2.0.0-1 tarball is an old one, it is
missing the upgrade instructions that were present in the 2.0.0
2. After converting kasp.db and bringing up the new software, all
zones were immediately re-signed, but the SOA in each zone was
reset to the (old) datetime value in the unsigned copy, which
is much lower than the value in the signed zonefiles produced
by 1.4.10 and earlier. Thus my secondary servers did not accept
the newly re-signed zones.
I suspect that this is related to some error messages I noted in
Jul 16 15:28:00 ns ods-signerd: [duration] cannot create from string 50: P not
Jul 16 15:28:00 ns ods-signerd: [duration] cannot create from string
datecounter: P not found
Jul 16 15:28:00 ns ods-signerd: [zone] corrupted backup file zone cacert.com:
read signconf error
Jul 16 15:28:00 ns ods-signerd: [engine] unable to recover zone cacert.com
from backup, performing full sign
which seems to indicate that the new signer cannot properly parse
the old intermediate files ... but there is nothing I can do about
that as a user, or is there?
I recovered from this bad state by manually increasing the SOA in
each unsigned zonefile, and issuing a re-sign for each of them.
3. The ods-enforcerd is logging requests which I do not understand,
ods-enforcerd: [enforce_task] please submit DS with keytag 62462 for
but the referenced key in each case is a ZSK according to key list:
cacert.org ZSK ready waiting for ds-submit
1024 7 1af3ac95b060f4b65fec26006587be18 SoftHSM 62462
cacert.org ZSK rumoured omnipresent
omnipresent rumoured 1 1 1af3ac95b060f4b65fec26006587be18
Why does this happen? What should I do about it?
4. For one (fortunately unimportant) zone, the situation is worse, the
ods-enforcerd tell me:
ods-enforcerd: [enforce_task] please retract DS with keytag 2701 for
ods-enforcerd: [enforce_task] please submit DS with keytag 65382 for
but key 2701 was until now my active KSK, while 65382 is a ZSK.
A new KSK 37255 has appeared for this zone in the key list, with state
'publish'. For the outside world the zone looks broken (the present DS
records/keys do not correspond to what's in the zone). It looks like
the 2.0.0. software has forced a KSK key roll for this zone without
me even asking ... is that expected behaviour??
More information about the Opendnssec-user