Andrew Hudson - Fedora™ Unleashed, 2008 edition

When your chrootenvironment is set up, you can start namedwith the -t /usr/local/ bindoption (combined with the -uand -goptions) to instruct it to chrootto the directory you have set up.

You might also want to check your logs and keep track of resource usage. namedmanages 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.conffile are available, including datasize, which limits the maximum size of the data segment and, therefore, the cache. One downside of this approach is that namedmight 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.

Several configuration options exist for namedthat 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 access control lists (ACLs) , which are named collections of network and IP addresses. You use these collections to ease the task of assigning permissions. Four predefined ACLs exist:

► 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 aclcommand as shown:

----------

acl trusted {

192.0.2.0/29; // Our own network is OK.

localhost; // And so is localhost.

!192.0.2.33/29; // But not this range.

};

----------

Here you see that you can use an exclamation point ( !) to negate members in an ACL. After they are defined, you can use these ACLs in allow-query, allow-transfer, allow-recursion, and similar options, as discussed next.

As mentioned before, most nameservers perform recursive resolution for any queries they receive unless specifically configured not to do so. (We suppressed this behavior by using dig +norec.) By repeatedly fetching data from a number of unknown and untrusted nameservers, recursion makes your installation vulnerable to DNS poisoning. (In other words, you get deliberately or inadvertently incorrect lists.) You can avoid this problem by explicitly denying recursion.

You can disable recursive queries by adding a recursion nostatement to the options section of named.conf. It might still be desirable to allow recursive queries from some trusted hosts, however, and this can be accomplished by the use of an allow-recursionstatement. This excerpt would configure namedto disallow recursion for all but the listed hosts:

----------

options {

...

recursion no;

allow-recursion {

192.0.2.0/29;

localnets; // Trust our local networks.

localhost; // And ourselves.

};

};

----------

You can choose to be still more restrictive and allow only selected hosts to query your nameserver by using the allow-query statement (with syntax similar to allow-recursion, as described previously). Of course, this solution does not work if your server is authoritative for a zone. In that case, you have to explicitly allow-query { all; }in the configuration section of each zone for which you want to serve authoritative data.

You also can use queries to enable only known slave servers to perform zone transfers from your server. Not only do zone transfers consume a lot of resources (they require a named-xferprocess to be forked each time) and provide an avenue for denial-of-service attacks, but also there have been remote exploits via buffer overflows in named-xferthat allow attackers to gain root privileges on the compromised system. To prevent this, add a section such as the following to all your zone definitions:

----------

zone "example.com" {

...

allow-transfer {

192.0.2.96; // Known slave.

localhost; // Often required for testing.

};

};

----------

Despite all this, it might be necessary to single out a few troublesome hosts for special treatment. The serverand blackholestatements in named.confcan be used to tell namedabout known sources of poisoned information or attack attempts. For instance, if the host 203.122.154.1is repeatedly trying to attack the server, the following addition to the options section of named.confcauses the server to ignore traffic from that address. Of course, you can specify multiple addresses and networks in the black-hole list:

----------

options { ...

blackhole { 203.122.154.1; };};

----------

For a known source of bad data, you can do something such as the following to cause your nameserver to stop asking the listed server any questions. This is different from adding a host to the black-hole list. A server marked as bogus is never sent queries, but it can still ask questions. A black-holed host is simply ignored altogether:

----------

server bogus.info.example.com { bogus yes;};

----------

The AUS-CERT advisory AL-1999.004, which discusses denial-of-service attacks against DNS servers, also discusses various ways of restricting access to nameservers and is a highly recommended read. A copy is located at ftp://ftp.auscert.org.au/pub/auscert/_advisory/AL-1999.004.dns_dos. Among other things, it recommends the most restrictive configuration possible and the permanent black-holing of some addresses known to be popular sources of spoofed requests and answers. It is a good idea to add the following ACL to the black-hole list of all your servers:

----------

/* These are known fake source addresses. */

acl "bogon" {

0.0.0.0/8; # Null address

1.0.0.0/8; # IANA reserved, popular fakes

2.0.0.0/8; 192.0.2.0/24; # Test address