Managing DNS Security
Security considerations are of vital importance to DNS administrators because DNS was not originally designed to be a secure protocol and a number of successful attacks against BIND have been found over the years. The most important defense is to keep abreast of developments in security circles and act on them promptly.
DNS is especially vulnerable to attacks known as poisoning and spoofing.
BIND has often been criticized as being very insecure, and although recent versions are greatly improved in this regard, DNS administrators today must take several precautions to ensure that its use is adequately protected from attacks. Of course, it is important to always run the latest recommended version of BIND.
One of your strongest defenses against DNS security risks is to keep abreast of developments in security circles and act on them promptly. The BugTraq mailing list, hosted at http://www.securityfocus.com/, and the SANS Institute, at http://www.sans.org/, are good places to start.
UNIX Security Considerations
The most important step in securing any UNIX system is to configure the environment BIND in which runs to use all the security mechanisms available to it through the operating system to its advantage. In short, this means that you should apply general security measures to your computer.
Run named with as few privileges as it needs to function. Do not run named as root. Even if an attacker manages to exploit a security hole in BIND, the effects of the break-in can be minimized if named is running as user nobody rather than as root. Of course, named has to be started as root because it needs to bind to port 53, but it can be instructed to switch to a given user and group with the -u and -g command-line options.
Starting named with a command such as named -u nobody -g nogroup is highly recommended. Remember, however, that if you run multiple services as nobody, you increase the risks of a compromise. In such a situation, it is best to create separate accounts for each service and use them for nothing else. Fedora runs named as the user named.
You can also use the chroot feature of UNIX to isolate named into its own part of the file system. If correctly configured, such a file system 'jail' restricts attackers — if they manage to break in — to a part of the file system that contains little of value. It is important to remember that a
Programs that use chroot but do not take any other precautions have been shown to be unsecure. BIND does take such additional precautions. See the chroot-BIND HOWTO at http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Chroot-BIND-HOWTO.html.
For a chroot environment to work properly, you have to set up a directory that contains everything BIND needs to run. It is recommended that you start with a working configuration of BIND, create a directory — say /usr/local/bind — and copy over the files it needs into subdirectories under that one. For instance, you have to copy the binaries, some system libraries, the configuration files, and so on. Consult the BIND documentation for details about exactly which files you need.
When your chroot environment is set up, you can start named with the -t /usr/local/ bind option (combined with the -u and -g options) to instruct it to chroot to the directory you have set up.
You might also want to check your logs and keep track of resource usage. named manages a cache of DNS data that can potentially grow very large; it happily hogs CPU and bandwidth also, making your server unusable. This is something that can be exploited by clever attackers, but you can configure BIND to set resource limits. Several such options in the named.conf file are available, including datasize, which limits the maximum size of the data segment and, therefore, the cache. One downside of this approach is that named might be killed by the kernel if it exceeds these limits, meaning that you have to run it in a loop that restarts it if it dies or run it from /etc/inittab.
DNS Security Considerations
Several configuration options exist for named that can make it more resistant to various potential attacks. The most common ones are briefly described next. For more detailed discussions of the syntax and use of these options, refer to the BIND 9 documentation.
The Security Level Configuration Tool (system-config-securitylevel) has been updated to make implementation of the firewall simpler. The new on/off choice (rather than levels as used before) allows you to employ a firewall without requiring any special configuration for your DNS server.
Specifying network and IP addresses multiple times in a configuration file is tedious and error prone. BIND allows you to define
> any — Matches anything
> none — Matches nothing
> localhost — Matches all the network interfaces local to your nameserver
> localnets — Matches any network directly attached to a local interface
In addition, you can define your own lists in named.conf, containing as many network and IP addresses as you prefer, using the acl command as shown:
----------
acl trusted {
192.0.2.0/29; // Our own network is OK.
localhost; // And so is localhost.
