key coverage tool

Curtis Blackburn ckb at isc.org
Mon Mar 12 18:03:31 UTC 2012


this is a work in progress and we are looking for feedback to make this a better tool.

As an administrator, I want a tool that allows me to be able to make sure that 
all the activation dates for my keys are valid.

This tool will be written in python.

This key coverage tool:
- ensure that there are no gaps in key coverage
- make sure that keys are published in your zone at least 1 ttl before that 
	key is to be published
- use refresh rate from SOA - e.g., ttl+refresh  to insure that key is 
	published soon enough

The following is a list of things that the tool will have to be able to 
gracefully handle whether by emitting a warning, an error, or information:

we expect to see one or more algorithm
within one algorithm we expect to see both a KSK and a ZSK
   - usually these will be different keys (warn if not?)
   - usually the KSK will have the SEP flag (warn if not?)
   - more than one KSK and ZSK is allowed

keys can be signed or unsigned 
keys can be published or unpublished
keys can be active or inactive
first look for any period of time where a key becomes inactive
   -error if a key following it would not be signed
   -error if a key following it would not be published
   -error if a key following it would not be active

warn if a ZSK remains published after it's been deactivated 
   -do not error as long as at least one ZSK is published and active

in the case of complex key rolls involving both KSKs and ZKSs 
   -we will need to alert the user of the time of the KSK roll
   -the user will need to ensure that the new DS is in place in the parent 
zone (can we check this with the tool?) 

in the case of zones with more than one algorithm in use
   -???

In the case of a zone being rolled from one algorithm to another
   -???


private section is extensible - ensure that when the .private part of KSKs and 
ZSKs is added to things continue to work

other possible scenarios that the tool may run into:

-corrupted fields/other bad input
-a zone with just KSKs
-a zone with just ZSKs
-deliberately going insecure
-nsec to nsec3 transitions
-vice versa
-non-readable keys
-non-writeable keys-(I do not think that this will be an issue) 
-revoked keys 
-bad key directory/other arguments
-inaccessible zone file
-it is possible to do some of the checking without using the zone file at all, 
do we want to do that?
-what if the key rolls havent taken place on time
*we didnt get an activated notification when we were supposed to


-- 
/***************************************\
* ISC offers support on many		*
* of its products, including BIND 9.	*
* If you depend on it, depend on us!  	*
\***************************************/

Curtis Blackburn
<ckb at isc.org>
Software Engineer, 
BIND Development Team
Internet Systems Consortium



More information about the bind-workers mailing list