each at isc.org
Wed Jan 8 17:15:19 UTC 2014
> Browsing through the man page for named.conf, the directive auto-dnssec
> is stated to allow the following values:
> auto-dnssec allow|maintain|create|off;
> The "create" option caught my attention, because it indicated that bind
> could perform not only automatic roll-overs of prepared keys with the
> correct meta-data from a specified directory, but also create new ZSK
> and KSK keys as necessary.
> After experimenting with this option, I found out that the latest BIND
> 9.9.4 considers it invalid, and googling further revealed to me that the
> directive had the "to-be-implemented" status in 9.9.7, only to be
> scraped altogether later (I found a changelog item mentioning removal of
> all referenced to it, so I consider the man-page reference to be an
Thanks for pointing that out, I'll correct it.
> Still, why was this highly useful option scraped? Was the reason effort
> to discourage bad practices of having the KSK key on the same machine
> that serves as the primary master?
No, I've just come to believe that named is the wrong place to put this
functionality. Among other problems, some platforms have random number
generators that will block waiting for entropy, so key generation can take
an unpredictable but large amount of time: you probably don't want your
name server doing that.
What I plan to do instead is write a new tool (or possibly extend the
existing dnssec-coverage tool) to allow you to define a key generation
policy -- that is, algorithms/key sizes, rollover frequency, prepublication
intervals, etc -- and automatically generate a sequence of keys to provide
DNSSEC coverage for a specified length of time into the future. So, for
example, if your policy is to roll ZSK's every nine months, you could tell
it to generate keys for the next three years, and it would create four ZSKs
with appropriate rollover characteristics. It could be run periodically
by cron, and it would check your current key coverage and generate new keys
if necessary; it could even send a "loadkeys" message to the server if
configured to do so.
This has been on my to-do list for quite a while, but other things
keep jumping into higher spots on the list.
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.
More information about the bind-users