With BIND 9.8, enabling DNSSec resolution and verification is now so simple and low-impact there’s absolutely no reason to not do it. Ignore the complicated tutorials filling the Internet. DNSSec is very easy on recursive servers.
DNS is the weak link in Internet security. Someone who can forge DNS entries in your server can use that to leverage his way further into your systems. DNSSec (mostly) solves this problem. Deploying DNSSec on your own domains is still fairly complicated, but telling a BIND DNS server to check for the presence of DNSSec is now simple.
In BIND 9.8.1 and newer (included with FreeBSD 9 and available for dang near everything else), add the following entries to your named.conf file.
options {
...
dnssec-enable yes;
dnssec-validation auto;
...
};
This configuration uses the predefined trust anchor for the root zone, which is what most of us should use.
Restart named. You’re done. If a domain is protected with DNSSec, your DNS server will reject forged entries.
To test everything at once, configure your desktop to use your newly DNSSec-aware resolver and browse to http://test.dnssec-or-not.org/. This gives you a simple yes or no answer. Verified DNSSec is indicated in dig(1) output by the presence of the ad (authenticated data) flag.
For the new year, add two lines to your named.conf today. Get all the DNSSec protection you can. Later, I’ll discuss adding DNSSec to authoritative domains.
Adding the above options blew one CPU sky high @ 100% on a FreeBSD 9.0-RELEASE !
George,
Definitely file a bug report. That should not happen.
But it’s definitely a reason for not enabling DNSSec in your environment…
I tried this also with Unbound awhile back; it’s similarly easy (from a configuration standpoint) there. But I had too many queries failing. The logs seemed to indicate upstream problems. It may have been something with my configuration, but not knowing the breadth (or lack thereof) of DNSSEC deployment, and therefore wanting to avoid needlessly beating my head against a wall trying to solve the problem, I gave up and reverted to “old” DNS.
DNSSEC it’s very useful to validate DNS data, but to encrypt dns queries will be interesting if you do an article about the Opendns dnscrypt-proxy.
Do you use it?
Personally i use in my Ubuntu server LTS.
https://www.opendns.com/technology/dnscrypt/
Regards,
I was able to replicate this. Be sure that your bind user can write to the working directory.
This might not be your problem, but it’s how I generated this error…
The working directory defaults to /etc/namedb, so “chown bind namedb”
Alternately, add options { managed-keys-directory “/etc/namedb/managed”; } and make sure that directory is writeable by bind.