[dns-operations] key management in bind9 (was Re: summary of recent vulnerabilities)
each at isc.org
Fri Oct 25 18:11:10 UTC 2013
> > BIND9 V9.9 may surprise you. it has inline signing and automatic key
> > management.
> I don't think it is a fair description of BIND 9.9 abilities. It does
> not manage keys (which, IMHO, mean creating them as necessary, remove
> them when outdated, change them intelligently depending on the TTL,
True that it doesn't create keys. We do have plans for an external tool to
do this -- probably to be written in python and run from cron, rather than
a built-in feature of named -- but we haven't had the necessary combination
of staff and time to write it yet.
If you, or anyone else reading, have specific requests for how such a tool
should work, I'd appreciate the input. I know we'll be wanting a policy
file to specify things like algorithm, key size, roll period, etc, but I'm
not sure I've thought of all the configuration knobs that would be useful.
I'd like to hear about any other areas where we could be doing a better
In the meantime, though, you can create as many keys in advance as you
like. It's easy to make a new key that's a direct successor to a previous
one using the -S option to dnssec-keygen; named will then move the keys in
and out of the zone on schedule.
# create initial ZSK
# set it to go inactive in 60 days and to be removed in 90
dnssec-settime -I now+60d -D now+90d $firstkey
# create a successor ZSK;
# it will prepublish in 30 days and activate in 60
secondkey=`dnssec-keygen -S $firstkey`
There's also a tool (dnssec-coverage) to check whether the scheduled
activation and inactivation dates for the keys you've created contain any
inadvertent lapses in coverage. For example, supposing the maximum TTL for
example.com is a week and the DNSKEY TTL is a day:
$ dnssec-coverage -m 7d -d 1d example.com
PHASE 1--Loading keys to check for internal timing problems
PHASE 2--Scanning future key events for coverage failures
Checking scheduled ZSK events for zone example.com, algorithm RSASHA1...
Fri Oct 25 17:45:36 UTC 2013:
Publish: example.com/005/53481 (ZSK)
Activate: example.com/005/53481 (ZSK)
Sun Nov 24 17:46:46 UTC 2013:
Publish: example.com/005/60972 (ZSK)
Tue Dec 24 17:46:46 UTC 2013:
Inactive: example.com/005/53481 (ZSK)
Activate: example.com/005/60972 (ZSK)
Thu Jan 23 17:46:46 UTC 2014:
Delete: example.com/005/53481 (ZSK)
No errors found
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.
More information about the dns-operations