Testing RFC 5011 key roll
warren at kumari.net
Mon Apr 20 20:17:57 UTC 2015
On Mon, Apr 20, 2015 at 3:41 PM, Edward Lewis <edward.lewis at icann.org> wrote:
> Thanks. rm'd the file and added the timers. (I did that also after
> sending, so it is the deleting the old file that did the trick.) The
> start-up lines look good.
> Got an AD bit again too.
> (I may have a few more issues as I move this off a laptop on to a regular
> machine. Right now it helps knowing where the loose bits are stored.)
Just FYI, the "current" key should always be at:
http://keyroll.systems/current , along with pre-built named.conf and
unbound.conf, suitable for cutting and pasting into config files.
That page says (for BIND):
"Note: When using this config file you will probably need to delete
every time you restart BIND after missing a keyroll." (I'm not quite
sure how that filename was derived...)
Jakob Schlyter created a nifty toolset at
https://github.com/jschlyter/keyroll/ to download the key, put it in
the right format, etc. It comes with config files for Unbound and
BIND, and makes using this simpler and easier!
> On 4/20/15, 15:12, "Evan Hunt" <each at isc.org> wrote:
>>On Mon, Apr 20, 2015 at 06:42:42PM +0000, Edward Lewis wrote:
>>> Being that I'm working on a laptop (hence on on over the weekend) I've
>>> to recreate the environment today. I'm a bit more puzzled now.
>>There's a separate file that named creates to keep the current
>>managed keys state information -- it's based on the view name,
>>so in your case it'll be "recursive.mkeys" (and possibly
>>"recursive.mkeys.jnl"). I suspect it still has the key from
>>Friday in it, and that's messing things up. Delete that file and
>>reinitialize, then leave the server up and running (not forgetting
>>to use -T mkeytimers=H/D/M, where M is no more than 3600 seconds,
>>because keyroll.systems rolls its keys every hour and normal RFC
>>5011 processing can't handle that), and you should be in good shape.
Actually it seems to be every 90 minutes at the moment.
keyroll.systems is very much a kludge....
>>Evan Hunt -- each at 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 at lists.isc.org
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
More information about the bind-users