key coverage tool

Spain, Dr. Jeffry A. spainj at countryday.net
Tue Mar 13 14:43:01 UTC 2012


I added a few comments below and would be happy to test your key coverage tool. I have a number of signed test zones running on bind 9.9.0 with inline signing and DNSSEC automatic key maintenance. For each zone there are two KSKs and 8 ZSKs covering a two-year period. ZSK rollovers happen every 3 months, and the KSKs are good for two years. Jeff.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School



> 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

Do you mean "key is to be activated"?

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

As I understand it, a ZSK needs to remain published for 30 days after it becomes inactive.
The key could have been used to sign a record just before it became inactive, and that
signature is good for 30 days. For performance reasons, bind 9 doesn't resign records just
because a key becomes inactive. The same is probably true of a KSK, although I have not
gone through a KSK rollover yet.

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

I think this is a ships-passing-in-the-night situation -- look at each algorithm separately.

> 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

This transition, and an nsec3 to nsec transition, happens pretty quickly in my experience. You would probably want to avoid analyzing a zone in transition, but I believe you can use the TYPE65534 records to tell you when the transition is complete.

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

The dnssec-settime utility (Bv9ARM.pdf, page 150) sets the permissions on any private keys where it alters the metadata to 0600. Thus if named is running as user bind, instead of root, then bind has to be the owner of the private keys, i.e. owner root and group bind doesn't work, as I discovered when DNSSEC stopped working on my test server. I think it would be a good idea to have the key coverage tool look at the permissions of various files and warn if they are not appropriate.

> -what if the key rolls havent taken place on time *we didnt get an activated notification when we were supposed to



More information about the bind-workers mailing list