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

[Yuri Schaeffer]

Hi Wytze,

I found a couple of errors in the migration script. Causing confusion in
the enforcer about the role of a key (ksk/zsk). I would advice you to
run the migration again but since you are live that might not be feasible.

If you are adventurous we could try to patch your database? Assuming you
are. Lets do this:

- stop opendnssec entirely
- backup your kasp.db
- run the following queries on your db:

UPDATE keyData
SET dsatparent = 0
WHERE role = 2;

UPDATE keyState
SET state = 4
WHERE (keyState.type = 0 OR keyState.type = 3) AND keyDataId IN (
       SELECT keyData.id
       FROM keyData
       WHERE keyData.role = 2);

UPDATE keyState
SET state = 4
WHERE keyState.type = 1 AND keyDataId IN (
       SELECT keyData.id
       FROM keyData
       WHERE keyData.role = 1);

This should get rid of those pesky ds-submit messages for ZSKs. And
prevent premature rollovers.

- start ODS back up
- Make sure the enforcer processed all zones. If needed run ods-enforcer
enforce; ods-enforcer signconf (we want to make sure it writes a new
signconf even if it thinks there is nothing to do);

> Well, after waiting a day, a somewhat friendlier solution has presented
> itself. After exoiry of a timer for the newly created KSK 330, the
> ods-enforcer key export -d *did* actually give me the DS records for
> KSK 330 (and some other useless ones). After uploading these DS records
> to the registrar, the zone did come back to life, and is basically
> looking healthy now.
> 
> Still, this is not a feasible method to repair my other zones, since
> I don't want to see them die DNSSEC-wise, while waiting for the timer
> to expire. Only after that (many hours later) ods-enforcer key export -d
> will finally give me the desired DS records.

I expect after fixing the DB this will give you correct results.

> I am wondering what criteria are applied by the code to decide which keys
> to export. It looks like they are wrong most of the time. Right now, with
> the zone restored to working state, it is exporting the DS for a retired
> ZSK. How could that ever be useful??

It isn't. Botched DB.

//Yuri

> 
> FYI, I have attached the output from key list -v and key list -d for this
> zone. The only exported key is now 13284 (retired ZSK).
> Even when I explicitly specify "key export -t KSK", it is still giving me
> this retired ZSK 13284.
> 
> Regards,
> -- wytze
> 
> 

-------------- 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/20160718/4251ff5b/attachment.bin>