« Previous article — Next article »

Securing DNS with a validating resolver

April 24th, 2009 Posted by D Webber

Few ISPs and web hosting providers pay attention to their DNS servers. Most use the same servers both to serve the domains they host and to perform name resolution (translating DNS names to IP addresses and vice versa). Many also allow recursive queries from anyone on the Internet, making DNS spoofing much easier.

We’ve had DNS security checks as part of our vulnerability assessments for years, and I’ve yet to encounter a provider’s DNS that is properly protected against attack. DNS tends to be yet another security blind spot, though it did get attention for a while when Dan Kaminsky’s cache poisoning exploit exploit made headlines last summer.

On the client side you can bypass your ISPs DNS with OpenDNS. It’s well maintained and offers a few other benefits like phishing filters.

However, OpenDNS is not meant for servers. For web servers or entire intranets, install a local resolver to go directly to the authoritative servers for each domain.

Using BIND is the default choice for this… it comes with all versions of Linux, but it’s memory intensive and has a history of security issues. Another popular choice is DNSCache, but it’s unmaintained and has some annoying dependencies and requirements.

A better choice is Unbound, a newer DNS caching resolver specifically designed for performance and security.

Unbound is developed by a NLNet, a Netherlands applied research group and supported by big names Verisign and Nominet. Its purpose is to be validating, recursive, and caching DNS resolver with good support for DNSSEC.

To be clear: Unbound is not for providing authoritative DNS. If you need to host DNS records so Internet users can can find your web sites and mail servers use BIND or other authoritative DNS configured to act only as an authoritative server.

Several DNS forgery protections are built in such as filtering private IP addresses from external DNS replies.

Want to block access to certain sites or services? Unbound also has handy features administrative features like  redirecting specific DNS queries to your own IP addresses… whether an entire domain or just specific records.

All this in a package that can be compiled easily on nearly any Linux or Unix, uses as much or as little memory as you tell it to, and has an easy configuration syntax. In short, Unbound rocks.

Compiling from source

Packaged versions of Unbound are in the Ubuntu Linux Universe repository starting with Hardy. Redhat doesn’t offer it yet. Regardless, new releases with many improvements come often and it’s easy to compile, so you’re better off building it yourself:

Download the latest source, extract the tarball then do the usual “./configure; make”. It depends on the libevent library, but the source includes an alternative if that is not installed.

Do “make install” to copy the libraries, executables and man pages to the right places (/usr/local/). A well-commented config file is installed in /usr/local/etc/unbound that has sensible defaults, but you should read through it. The daemon also runs chrooted from that directory.

Installing

Add a user and group to the OS named “unbound” and lock it from interactive access with “passwd -l”.

Download the latest root DNS hints file from ftp://FTP.INTERNIC.NET/domain/named.cache and place it in /usr/local/etc/unbound. Make sure user “unbound” has read permissions on the named.cache file. Edit the unbound.conf file to change the setting “root-hints” to point to /usr/local/etc/unbound/named.cache.

To test the installation, start the daemon from the command line by typing “unbound”. If it works, you will see a process named “unbound” running. If not, errors are written to syslog: check /var/log/daemon.log, /var/log/messages or whereever your system’s syslog writes daemon messages.

Once running, try a few lookups using dig, e.g.:

dig @127.0.0.1 www.advosys.ca

Configure the server to use Unbound for DNS lookups by editing file /etc/resolv.conf to add the following to the top:

nameserver 127.0.0.1

Now the part everyone hates: writing the startup script. For Unbound to start automatically when the server boots, a suitable script must be placed in /etc/init.d (for most Unix and Linux systems) then symlinked to appropriately named files in the /etc/rc.x directories.

To save you some work, we’ve written the following simple startup scripts for Unbound:

Place the appropriate script in directory /etc/init.d, rename it to “unbound” then use the install method appropriate to your version of Linux:

Redhat / CentOS:

chkconfig --add unbound
chkconfig unbound on

Ubuntu / Debian:

update-rc.d unbound defaults

There are several options in the unbound.conf configuration file worth customizing, e.g. to disable IPv6 if you’re not using that, add sanity checks to weed out spoofed DNS replies, etc.  However, Unbound works well right out of the box in most situations.

With a good caching resolver like Unbound, your servers can directly query authoritative DNS servers, bypassing your provider’s probably polluted DNS. At the cost of slightly more network traffic and more memory usage, you can be reasonably confident that DNS answers legitimate and not pointing to malicious IP addresses.

Related posts:

Posted in Best practices, Infrastructure |
Tags: ,

Comments for this article are closed.