DNSSec and DLV on current BIND

One of the problems with the Internet is that old stuff hangs around forever. Configuring DNSSec validation on BIND 9.8 and newer is a lot easier than many of the popular tutorials would lead you to suspect. It’s so simple that I wonder why it isn’t the default.

options {
...
dnssec-enable yes;
dnssec-validation auto;
dnssec-lookaside auto;
};

This automatically loads the root zone and dlv.isc.org trust anchors distributed with the BIND source code, verifies them, and uses them to validate all signed responses.

One trick is that named needs to write journal files for these keys. If you used the directory option to set a directory writable by named, you’re all set. If, like me, you have a whole bunch of directories that you don’t want named to write to, and you don’t want named to write to /etc/namedb, you can set a directory for these named-managed keys.

/var/log/messages will have errors like this:

Jan 7 11:59:02 ns11 named[78246]: the working directory is not writable

These errors are harmless. named cannot write /etc/namedb, but it will log an error when it tries to write a file. The errors you need to worry about look like this:

Jan 5 13:07:05 ns11 named[68130]: dumping master file: tmp-XI0K5awL6p: open: permission denied

These indicate that named is trying to record important data, and can’t. Giving named a directory where it can write these managed key files will solve this problem.

options {
...
managed-keys-directory "managed-keys";
}

Make that directory owned by the user running named. Restart (not reload) named, and you’re all set.

One of the rules of public key encryption is that your private key must be private. Most of us have had private keys stolen at some time. (If you haven’t, either you’re not using public key crypto, or you didn’t notice.) What happens if someone steals the private key for a DNSSec trust anchor?

There’s a protocol for automatically updating the trust anchor private keys, documented in RFC 5011. It’s not perfect — you’ll still want to keep half an eye out for announcements of a trust anchor compromise.

On a related note, I’d be interested in hearing from anyone who knows how the root zone private key is protected, just so I can put a sentence or two in the DNSSec book.