> 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 > omission).
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 -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
