[dns-operations] key management in bind9 (was Re: summary of recent vulnerabilities)

[Evan Hunt]

Hi Stephane,

> > 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,
> etc). 

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
job, too.

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
    firstkey=`dnssec-keygen example.com`

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