10.11.1 BIND Version

One of the most important ways you can enhance the security of your name server is to run the latest version of BIND . All versions of BIND before 4.9.7 are susceptible to at least a few known attacks.[4] BIND 8.1.2 is an even better bet, because of the many new security mechanisms it introduced.

[4] In fact, part of the reason there is a BIND 4.9.7, and the BIND 4 release stream didn't stop with 4.9.6, was 4.9.6's vulnerability to a particular attack.

But don't stop there: New attacks are being thought up all the time, so you'll have to do your best to keep abreast of BIND 's vulnerabilities and the latest "safe" version of BIND . One good way to do that is to read the newsgroup comp.protocols.dns.bind regularly.

10.11.2 Restricting Queries

Up until BIND 4.9, domain administrators had no way to control who could look up data on their name servers. That makes a certain amount of sense; the original idea behind DNS was to make information easily available all over the Internet.

The neighborhood is not such a friendly place anymore, though. In particular, people who run Internet firewalls may have a legitimate need to hide certain parts of their name space from most of the world but to make it available to a limited audience.

The BIND 8 allow-query substatement allows you to place an IP address-based access list on queries. The access list can apply to a particular zone, or to any queries received by the server. In particular, the access list specifies which IP addresses are allowed to send queries to the server.

10.11.3 Preventing Unauthorized Zone Transfers

Even more important than controlling who can query your name server is ensuring that only your real slave name servers can transfer zones from your name server. Users on remote hosts that can query your name server's zone data can only look up data (e.g., addresses) for hosts whose domain names they already know, one at a time. Users who can start zone transfers from your server can list all of the hosts in your zones. It's the difference between letting random folks call your company's switchboard and ask for John Q. Cubicle's phone number and sending them a copy of your corporate phone directory.

BIND 8's allow-transfer substatement and 4.9's xfrnets directive let administrators apply an access list to zone transfers. allow-transfer can restrict transfers of a particular zone as a zone substatement or can restrict all zone transfers as an options substatement. It takes an address match list as an argument.

Say the slave servers for your acmebw.com zone have the IP addresses 192.168.0.1 and 192.168.1.1. The zone statement:

zone "acmebw.com" {
                type master;
                file "db.acmebw";
                allow-transfer { 192.168.0.1; 192.168.1.1; };
};

will allow only those slaves to transfer acmebw.com from the primary master name server. Note that since BIND 8's default is to allow any IP address to transfer zones, and because hackers can just as easily transfer the zone from your slaves, you should probably also have a zone statement like this on your slaves:

zone "acmebw.com" {
                type slave;
                masters { 192.168.0.4; };
                allow-transfer { none; };
};

BIND 8 will also let you establish a global access list on zone transfers. This applies to any zones that don't have their own, explicit access lists defined as zone substatements. For example, you might want to limit all zone transfers to your internal IP addresses:

options {
                allow-transfer { 192.168/16; };
};

The BIND 4.9 xfrnets directive takes as its arguments the networks or IP addresses you'd like to allow to transfer zones from your name server. Networks are specified by the dotted-octet form of the network number; for example:

xfrnets 15.0.0.0 128.32.0.0

allows only hosts on the Class A network 15 or the Class B network 128.32 to transfer zones from this name server. Unlike secure zones, this restriction applies to any zones the server is authoritative for.

If you want to specify just a part of the network, down to a single IP address, you can add a network mask. The syntax for including a network mask is network&netmask . Note that there are no spaces either between the network and the ampersand or between the ampersand and the netmask: they're not allowed.

To pare down the addresses allowed to transfer zones in the previous example to just the IP address 15.255.152.4 and the subnet 128.32.1.0, you could use the xfrnets directive:

xfrnets 15.255.152.4&255.255.255.255 128.32.1.0&255.255.255.0

For a primary master name server accessible from the Internet, you probably want to limit zone transfers to just your slave name servers. You probably don't need to use xfrnets on name servers inside your firewall, unless you're worried about your own employees listing your zone data.

10.11.4 Running BIND as a Non-Root User

Running a network server such as BIND as the root user can be dangerous - and BIND normally runs as root. If a hacker finds a vulnerability in the server through which he can read or write files, he'll have root access to the filesystem. If he can exploit a flaw that allows him to execute commands, he'll execute them as root.

BIND 8.1.2 includes experimental code that allows you to change the user and group the name server runs as. This allows you to run the name server with what's known as "least privilege:" the minimal set of rights it needs to do its job. That way, if someone is able to break into your host through the name server, at least they won't have root privileges.

BIND 8.1.2 also includes an option that allows you to chroot the name server: to change its view of the filesystem so that its root directory is actually a particular directory on your host's filesystem. This effectively traps your name server in this directory, along with any attackers who successfully compromise your name server's security.

The command-line options that implement these features are:

-u

Specifies the username or user ID the name server changes to after starting, e.g., named -u bin .

-g

Specifies the group or group ID the name server changes to after starting, e.g., named -g other . If -u is specified without -g , the name server will use the user's primary group.

-t

Specifies the directory for the name server to chroot to.

If you opt to use the -u and -g options, you'll have to decide what user and group to use. Your best bet is to create a new user and group for the name server to run as, such as named . Since the name server reads named.conf before giving up root privileges, you don't have to change that file's permissions. However, you may have to change the permissions and ownership of your zone data files so that the user the name server runs as can read them. If you use dynamic update, you'll have to make the zone data files for dynamically-updated zones writable by the name server.

The name server may have trouble writing the named.pid file, too, since it occasionally rewrites it after startup (and after giving up root privileges). On most versions of UNIX , /var/run (the directory in which the name server saves named.pid ) isn't writable by non-root users. The easiest way to deal with this is to use the pid-file substatement to move named.pid to another directory:

options {
                pid-file "/var/named/named.pid";
};

Then make sure that file is writable by the user named runs as.

If your name server is configured to log to files (as opposed to syslog), make sure those files exist and are writable by the name server before starting the server.

The -t option takes a little more special configuration. In particular, you need to make sure that all the files named uses are present in the directory you're restricting the server to. That includes the following:

named-xfer

Most named s expect to find the named-xfer executable in /etc/named-xfer . If you chroot the server to /var/named , that becomes /var/named/etc/named-xfer .

Shared libraries

If you build the name server with shared libraries, you'll need to put copies of those shared libraries in whatever directory your operating system expects them in. For example, if your OS looks for shared libraries in /lib , you'll need copies in /var/named/lib . The alternative is to build your name server as a statically-linked executable.

/dev/null

The name server needs a /dev/null in the chroot ed directory. You can find out how to make one by reading /dev/MKDEV , or the manual page for mknod .

Finally, the name server may not be able to syslog in a chroot ed environment. If that's the case, use the logging statement described in Chapter 7, Maintaining BIND , to log to files in the chroot ed directory.

With any of these options, you'll have to remember to either edit ndc to specify the options upon restart or start, or to start and restart named manually.

10.11.5 "Delegated" Name Server Configuration

Some of your name servers answer nonrecursive queries from other name servers on the Internet, because your name servers appear in NS records delegating your zones to them. We'll call these name servers "delegated" name servers.

There are special measures you can take to secure your delegated name servers. But first, you should make sure that these servers don't receive any recursive queries (that is, you don't have any resolvers configured to use these servers, and no name servers use them as forwarders). Some of the precautions we'll take - like making the server respond nonrecursively even to recursive queries - preclude your resolvers from using these servers. If you do have resolvers using your delegated name servers, consider establishing another class of name servers to serve just your resolvers, as described in the next section.

Once you know your name server only answers queries from other name servers, you can turn off recursion. This eliminates a major vector of attack: the most common spoofing attacks involve inducing the target name server to query name servers under the hacker's control by sending the target a recursive query for a domain name in a zone served by the hacker's servers. To turn off recursion, you'd use:

options {
                recursion no;
};

on a BIND 8 server, and:

options no-recursion

on a BIND 4.9 server.

You should also restrict zone transfers of your zones to known slave servers, as described in Section 10.11.3, "Preventing Unauthorized Zone Transfers ," earlier in this chapter. Finally, you might also want to turn off glue fetching. The name server will automatically try to resolve the names of any name servers in the RDATA of NS records; to prevent this from happening, and keep your name server from sending any queries of its own, use:

options {
                fetch-glue no;
};

on a BIND 8 server, and:

options no-fetch-glue

on BIND 4.9.

10.11.6 Resolving Name Server Configuration

We'll call a name server that serves one or more resolvers, or is configured as another name server's forwarder, a "resolving" name server. Unlike a delegated name server, a "resolving" name server can't refuse recursive queries. Consequently, we have to configure it a little differently to secure it. Since we know our name server should only receive queries from our own resolvers, we can configure it to deny queries from any but our resolvers' IP addresses.

Only BIND 8 will allow us to restrict which IP addresses can send our name server arbitrary queries. ( BIND 4.9 servers will let us restrict which IP addresses can send the server queries in authoritative zones, via the secure_zone TXT record, but we're actually more worried about recursive queries in others' zones.) This allow-query substatement will restrict queries to just our internal network:

options {
                allow-query { 192.168/16; };
};

With this configuration, the only resolvers that can send your server recursive queries, and induce your name servers to query other name servers, are your internal resolvers, which are presumably relatively benevolent.

10.11.7 Two Name Servers in One

What if you only have one name server to advertise your zone and serve your resolvers, and you can't afford the additional expense of buying another computer to run another name server on? There are still a couple of options open to you. One is a single-server solution that takes advantage of BIND 8's flexibility. This configuration allows anyone to query the name server for information in your delegated zones, but only your internal resolvers can query the name server for other information. While this doesn't prevent remote resolvers from sending your name server recursive queries, those queries have to be in your authoritative zones, so they won't induce your name server to send additional queries.

Here's a named.conf file to do that:

options {
                allow-query { 192.168/16; };
};

zone "acmebw.com" {
                type master;
                file "db.acmebw";
                allow-query { any };
                allow-transfer { 192.168.0.1; 192.168.1.1; };
};

zone "168.192.in-addr.arpa" {
                type master;
                file "db.192.168";
                allow-query { any; };
                allow-transfer { 192.168.0.1; 192.168.1.1; };
};

Here, the more permissive zone-specific access lists apply to queries in the server's authoritative zones, but the more restrictive global access list applies to all other queries.

Another option is to run two named processes on a single host. One is configured as the delegated server, another as the resolving name server. Since we have no way of telling remote servers or configuring resolvers to query one of our name servers on a port other than 53, the default DNS port, we have to run these servers on different IP addresses.

Of course, if your host already has more than one network interface, that's no problem. Even if it only has one, the operating system may support IP address aliases. These allow you to attach more than one IP address to a single network interface. One named process can listen on each. Finally, if the operating system doesn't support IP aliases, you can still bind one named against the network interface's IP address, and one against the loopback address. Only the local host will be able to send queries to the named listening on the loopback address, but that's fine if the local host's resolver is the only one you need to serve.

First, here's the named.conf file for the delegated name server, listening on the network interface's IP address:

options {
                directory "/usr/local/named";
                recursion no;
                listen-on { 192.168.0.4; };
                pid-file "delegated.pid";
};

zone "acmebw.com" {
                type master;
                file "db.acmebw";
                allow-query { any };
                allow-transfer { 192.168.0.1; 192.168.1.1; };
};

zone "168.192.in-addr.arpa" {
                type master;
                file "db.192.168";
                allow-query { any; };
                allow-transfer { 192.168.0.1; 192.168.1.1; };
};

zone "." {
                type hint;
                file "db.cache";
};

Next, here's the named.conf file for the resolving name server, listening on the loopback address:

options {
                directory "/usr/local/named1";
                listen-on { 127.0.0.1; };
                pid-file "resolving.pid";
};

zone "." {
                type hint;
                file "db.cache";
};

The listen-on substatement tells the server reading the conf file to listen only on network interfaces whose IP addresses match the address match list. We've specified the IP address explicitly, so that there's no chance of mistakes. You can also use listen-on to have named listen on a port other than 53; for that, use the syntax:

options {
                listen-on port <n> { address_match_list };
};

Note that we turn recursion off on the delegated name server, but must leave it on on the resolving name server. We also give each name server its own PID file and its own directory, so that they don't try to use the same default filename for their PID files, debug files, and statistics files.

To use the resolving name server, listening on the loopback address, the local host's resolv.conf file must include:

nameserver 127.0.0.1

as the first nameserver directive.