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

[Yuri Schaeffer]

Hi Wytze,

I'll try to answer as much as possible with what comes to mind. Further
analysis will have to wait a bit.

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

That's odd. All I did change was a Makefile.am. There must have been
something that has gone wrong in our release process. Will investigate.

> 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 think 2.0.0 *should* be able to parse the 1.4.10 signconf files.
However I'm less sure about earlier versions. At this point I'm not
entirely sure there is an upgrade path that allows one to keep the
signconf from old versions. This may mean loosing the SOA serial. We
need to properly document/guide this I think.

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

This is not right at all. The key identifies as a ZSK, but looks more
like a CSK (zsk+ksk)! I recommend to initiate a rollover for that zone.
For both the ksk and zsk. Make sure your policy in kasp.xml looks good.

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

It should not ask that for a ZSK. Something has gone wrong with the
database conversion I guess. Do you still have the database as produced
by 1.4.10? I'd like to compare it to your 2.0.0 database.

The second part: yes. Unless you specified <ManualRollover> for the KSK
it will automatically roll as your policy prescribes. However if you
don't indicate you retracted the old DS I expect both DNSKEYS to be
published in your zone. And therefore not broken. Is this not the case?


Kind regards,
Yuri

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20160716/4e2eee95/attachment.bin>