[Opendnssec-user] End-of-life OpenDNSSEC 1.3 on 2017-07-11

[Wytze van der Raay]

Hi Yuri,

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
   tarball.

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
   the logs:
Jul 16 15:28:00 ns ods-signerd: [duration] cannot create from string 50: P not
found
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,
   for example:

      ods-enforcerd: [enforce_task] please submit DS with keytag 62462 for
zone cacert.org

   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
zone cacert.community
      ods-enforcerd: [enforce_task] please submit DS with keytag 65382 for
zone cacert.community

    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??

Regards,
-- wytze