Mathieu Arnold reported on the user list that he was getting error messages reporting there were not enough KSK keys allocated for the number of zones that he had. An investigation revealed that in his database, 3 of his zones had 2 KSK allocated, one which was the active key and another which was allocated to the zone, but was in the generate state:
mysql> SELECT * FROM KEYDATA_VIEW WHERE policy_id = 1 AND securitymodule_id = 2 AND size = 2048 AND algorithm = 8 AND (STATE IN (1, 2, 3, 4, 7, 8, 9) or STATE is NULL) and (RETIRE > DATE_ADD('2014-02-05 12:00:00', INTERVAL 30000 SECOND) or RETIRE is NULL) AND zone_id in (1015, 1016, 1017) order by zone_id, state;
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| id | state | generate | publish | ready | active | retire | dead | keytype | algorithm | location | zone_id | policy_id | securitymodule_id | size | compromisedflag | fixedDate |
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 21634 | 1 | 2013-12-06 17:11:39 | NULL | NULL | NULL | NULL | NULL | 257 | 8 | 712cd2f236fe7ac7d0e584a350d32105 | 1015 | 1 | 2 | 2048 | NULL | 0 |
| 13115 | 4 | 2013-10-01 09:52:45 | 2013-10-08 05:12:59 | 2013-10-08 10:12:59 | 2013-10-01 21:19:18 | 2014-09-16 21:19:18 | NULL | 257 | 8 | 2d126ae4e94e9a012173dde3f37a0b9f | 1015 | 1 | 2 | 2048 | NULL | 0 |
| 21635 | 1 | 2013-12-06 17:11:39 | NULL | NULL | NULL | NULL | NULL | 257 | 8 | cc7701b0e313b9252ebab2ac83528fd9 | 1016 | 1 | 2 | 2048 | NULL | 0 |
| 13116 | 4 | 2013-10-01 09:52:45 | 2013-10-08 05:12:59 | 2013-10-08 10:12:59 | 2013-10-01 21:19:24 | 2014-09-16 21:19:24 | NULL | 257 | 8 | 73ba8698fcc8e2fcbd5269cd09484073 | 1016 | 1 | 2 | 2048 | NULL | 0 |
| 21636 | 1 | 2013-12-06 17:11:39 | NULL | NULL | NULL | NULL | NULL | 257 | 8 | 557ca755b651bc4f4e98fef3abca6db4 | 1017 | 1 | 2 | 2048 | NULL | 0 |
| 13117 | 4 | 2013-10-01 09:52:45 | 2013-10-08 05:12:59 | 2013-10-08 10:12:59 | 2013-10-01 21:19:30 | 2014-09-16 21:19:30 | NULL | 257 | 8 | b603f45566354b9990d1f6af8ec97a65 | 1017 | 1 | 2 | 2048 | NULL | 0 |
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
6 rows in set (0.00 sec)
It should not possible for a key to get to this state, as is should either be generated but unallocated, or allocated and further through the key lifecycle.
The problem keys can be deleted via the command line as an immediate solution. However
1) it is not understood how the keys got into this state - need to review the enforcer code and test some scenarios
2) it would be nice to implement some kind of key audit that would automatically clean up keys if they ever got in this state. Perhaps we could offer another option on the 'key purge' command to purge keys in this 'hung' state?
- is cloned by
-
OPENDNSSEC-586 CLONE - Keys can be allocated to a zone but get stuck in the generate state
-
- Closed
-