23.6 Domain Name System (DNS)

23.6.1 Overview

FreeBSD utilizes, by default, a version of BIND (Berkeley Internet Name Domain), which is the most common implementation of the DNS protocol. DNS is the protocol through which names are mapped to IP addresses, and vice versa. For example, a query for www.FreeBSD.org will receive a reply with the IP address of The FreeBSD Project's web server, whereas, a query for ftp.FreeBSD.org will return the IP address of the corresponding FTP machine. Likewise, the opposite can happen. A query for an IP address can resolve its hostname. It is not necessary to run a name server to perform DNS lookups on a system.

DNS is coordinated across the Internet through a somewhat complex system of authoritative root name servers, and other smaller-scale name servers who host and cache individual domain information.

This document refers to BIND 8.x, as it is the stable version used in FreeBSD. Versions of FreeBSD 5.3 and beyond include BIND9 and the configuration instructions may be found later in this chapter. Users of FreeBSD 5.2 and other previous versions may install BIND9 from the net/bind9 port.

RFC1034 and RFC1035 dictate the DNS protocol.

Currently, BIND is maintained by the Internet Software Consortium http://www.isc.org/.

23.6.2 Terminology

To understand this document, some terms related to DNS must be understood.

Examples of zones:

• . is the root zone

• org. is a zone under the root zone

• example.org. is a zone under the org. zone

• foo.example.org. is a subdomain, a zone under the example.org. zone

• 1.2.3.in-addr.arpa is a zone referencing all IP addresses which fall under the 3.2.1.* IP space.

As one can see, the more specific part of a hostname appears to its left. For example, example.org. is more specific than org., as org. is more specific than the root zone. The layout of each part of a hostname is much like a filesystem: the /dev directory falls within the root, and so on.

23.6.3 Reasons to Run a Name Server

Name servers usually come in two forms: an authoritative name server, and a caching name server.

An authoritative name server is needed when:

• one wants to serve DNS information to the world, replying authoritatively to queries.

• a domain, such as example.org, is registered and IP addresses need to be assigned to hostnames under it.

• an IP address block requires reverse DNS entries (IP to hostname).

• a backup name server, called a slave, must reply to queries when the primary is down or inaccessible.

A caching name server is needed when:

• a local DNS server may cache and respond more quickly than querying an outside name server.

• a reduction in overall network traffic is desired (DNS traffic has been measured to account for 5% or more of total Internet traffic).

When one queries for www.FreeBSD.org, the resolver usually queries the uplink ISP's name server, and retrieves the reply. With a local, caching DNS server, the query only has to be made once to the outside world by the caching DNS server. Every additional query will not have to look to the outside of the local network, since the information is cached locally.

23.6.4 How It Works

In FreeBSD, the BIND daemon is called named for obvious reasons.

Zone files are usually contained within the /etc/namedb directory, and contain the DNS zone information served by the name server.

23.6.5 Starting BIND

Since BIND is installed by default, configuring it all is relatively simple.

To ensure the named daemon is started at boot, put the following line in /etc/rc.conf:

named_enable="YES"

To start the daemon manually (after configuring it):

# ndc start

23.6.6 Configuration Files

# cd /etc/namedb
# sh make-localhost

// $FreeBSD$
//
// Refer to the named(8) manual page for details.  If you are ever going
// to setup a primary server, make sure you've understood the hairy
// details of how DNS is working.  Even with simple mistakes, you can
// break connectivity for affected parties, or cause huge amount of
// useless Internet traffic.

options {
        directory "/etc/namedb";

// In addition to the "forwarders" clause, you can force your name
// server to never initiate queries of its own, but always ask its
// forwarders only, by enabling the following line:
//
//      forward only;

// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below.  This will make you
// benefit from its cache, thus reduce overall DNS traffic in the
Internet.
/*
        forwarders {
                127.0.0.1;
        };
*/

        /*
         * If there is a firewall between you and name servers you want
         * to talk to, you might need to uncomment the query-source
         * directive below.  Previous versions of BIND always asked
         * questions using port 53, but BIND 8.1 uses an unprivileged
         * port by default.
         */
        // query-source address * port 53;

        /*
         * If running in a sandbox, you may have to specify a different
         * location for the dumpfile.
         */
        // dump-file "s/named_dump.db";
};

// Note: the following will be supported in a future release.
/*
host { any; } {
        topology {
                127.0.0.0/8;
        };
};
*/

// Setting up secondaries is way easier and the rough picture for this
// is explained below.
//
// If you enable a local name server, don't forget to enter 127.0.0.1
// into your /etc/resolv.conf so this server will be queried first.
// Also, make sure to enable it in /etc/rc.conf.

zone "." {
        type hint;
        file "named.root";
};

zone "0.0.127.IN-ADDR.ARPA" {
        type master;
        file "localhost.rev";
};

zone
"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" {
        type master;
        file "localhost.rev";
};

// NB: Do not use the IP addresses below, they are faked, and only
// serve demonstration/documentation purposes!
//
// Example secondary config entries.  It can be convenient to become
// a secondary at least for the zone where your own domain is in.  Ask
// your network administrator for the IP address of the responsible
// primary.
//
// Never forget to include the reverse lookup (IN-ADDR.ARPA) zone!
// (This is the first bytes of the respective IP address, in reverse
// order, with ".IN-ADDR.ARPA" appended.)
//
// Before starting to setup a primary zone, better make sure you fully
// understand how DNS and BIND works, however.  There are sometimes
// unobvious pitfalls.  Setting up a secondary is comparably simpler.
//
// NB: Don't blindly enable the examples below. :-)  Use actual names
// and addresses instead.
//
// NOTE!!! FreeBSD runs BIND in a sandbox (see named_flags in rc.conf).
// The directory containing the secondary zones must be write accessible
// to BIND.  The following sequence is suggested:
//
//      mkdir /etc/namedb/s
//      chown bind:bind /etc/namedb/s
//      chmod 750 /etc/namedb/s

/*
zone "example.com" {
        type slave;
        file "s/example.com.bak";
        masters {
                192.168.1.1;
        };
};

zone "0.168.192.in-addr.arpa" {
        type slave;
        file "s/0.168.192.in-addr.arpa.bak";
        masters {
                192.168.1.1;
        };
};
*/

zone "example.org" {
    type master;
    file "example.org";
};

zone "example.org" {
    type slave;
    file "example.org";
};

$TTL 3600

example.org. IN SOA ns1.example.org. admin.example.org. (
                        5               ; Serial
                        10800           ; Refresh
                        3600            ; Retry
                        604800          ; Expire
                        86400 )         ; Minimum TTL

; DNS Servers
@       IN NS           ns1.example.org.
@       IN NS           ns2.example.org.

; Machine Names
localhost       IN A    127.0.0.1
ns1             IN A    3.2.1.2
ns2             IN A    3.2.1.3
mail            IN A    3.2.1.10
@               IN A    3.2.1.30

; Aliases
www             IN CNAME        @

; MX Record
@               IN MX   10      mail.example.org.

recordname      IN recordtype   value

example.org. IN SOA ns1.example.org. admin.example.org. (
                        5               ; Serial
                        10800           ; Refresh after 3 hours
                        3600            ; Retry after 1 hour
                        604800          ; Expire after 1 week
                        86400 )         ; Minimum TTL of 1 day

@       IN NS           ns1.example.org.

localhost       IN A    127.0.0.1
ns1             IN A    3.2.1.2
ns2             IN A    3.2.1.3
mail            IN A    3.2.1.10
@               IN A    3.2.1.30

www             IN CNAME        @

@               IN MX   10      mail.example.org.

$TTL 3600

1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (
                        5               ; Serial
                        10800           ; Refresh
                        3600            ; Retry
                        604800          ; Expire
                        3600 )          ; Minimum

@       IN NS   ns1.example.org.
@       IN NS   ns2.example.org.

2       IN PTR  ns1.example.org.
3       IN PTR  ns2.example.org.
10      IN PTR  mail.example.org.
30      IN PTR  example.org.

23.6.7 Caching Name Server

A caching name server is a name server that is not authoritative for any zones. It simply asks queries of its own, and remembers them for later use. To set one up, just configure the name server as usual, omitting any inclusions of zones.

23.6.8 Running named in a Sandbox

For added security you may want to run named(8) as an unprivileged user, and configure it to chroot(8) into a sandbox directory. This makes everything outside of the sandbox inaccessible to the named daemon. Should named be compromised, this will help to reduce the damage that can be caused. By default, FreeBSD has a user and a group called bind, intended for this use.

Since named will not be able to access anything outside of the sandbox (such as shared libraries, log sockets, and so on), there are a number of steps that need to be followed in order to allow named to function correctly. In the following checklist, it is assumed that the path to the sandbox is /etc/namedb and that you have made no prior modifications to the contents of this directory. Perform the following steps as root:

• Create all directories that named expects to see:

  # cd /etc/namedb
  # mkdir -p bin dev etc var/tmp var/run master slave
  # chown bind:bind slave var/*
  

  

  named only needs write access to these directories, so that is all we give it.

• Rearrange and create basic zone and configuration files:

  # cp /etc/localtime etc
  # mv named.conf etc && ln -sf etc/named.conf
  # mv named.root master
  # sh make-localhost && mv localhost.rev localhost-v6.rev master
  # cat > master/named.localhost
  $ORIGIN localhost.
  $TTL 6h
  @   IN  SOA localhost. postmaster.localhost. (
              1   ; serial
              3600    ; refresh
              1800    ; retry
              604800  ; expiration
              3600 )  ; minimum
      IN  NS  localhost.
      IN  A       127.0.0.1
  ^D
  

  

  This allows named to log the correct time to syslogd(8).

• If you are running a version of FreeBSD prior to 4.9-RELEASE, build a statically linked copy of named-xfer, and copy it into the sandbox:

  # cd /usr/src/lib/libisc
  # make cleandir && make cleandir && make depend && make all
  # cd /usr/src/lib/libbind
  # make cleandir && make cleandir && make depend && make all
  # cd /usr/src/libexec/named-xfer
  # make cleandir && make cleandir && make depend && make NOSHARED=yes all
  # cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer
  

  After your statically linked named-xfer is installed some cleaning up is required, to avoid leaving stale copies of libraries or programs in your source tree:

  # cd /usr/src/lib/libisc
  # make cleandir
  # cd /usr/src/lib/libbind
  # make cleandir
  # cd /usr/src/libexec/named-xfer
  # make cleandir
  

  

  This step has been reported to fail occasionally. If this happens to you, then issue the command:

  # cd /usr/src && make cleandir && make cleandir
  

  and delete your /usr/obj tree:

  # rm -fr /usr/obj && mkdir /usr/obj
  

  This will clean out any “cruft” from your source tree, and retrying the steps above should then work.

  If you are running FreeBSD version 4.9-RELEASE or later, then the copy of named-xfer in /usr/libexec is statically linked by default, and you can simply use cp(1) to copy it into your sandbox.

• Make a dev/null that named can see and write to:

  # cd /etc/namedb/dev && mknod null c 2 2
  # chmod 666 null
  

• Symlink /var/run/ndc to /etc/namedb/var/run/ndc:

  # ln -sf /etc/namedb/var/run/ndc /var/run/ndc
  

  Note: This simply avoids having to specify the -c option to ndc(8) every time you run it. Since the contents of /var/run are deleted on boot, it may be useful to add this command to root's crontab(5), using the @reboot option.

• Configure syslogd(8) to create an extra log socket that named can write to. To do this, add -l /etc/namedb/dev/log to the syslogd_flags variable in /etc/rc.conf.

• Arrange to have named start and chroot itself to the sandbox by adding the following to /etc/rc.conf:

  named_enable="YES"
  named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf"
  

  Note: Note that the configuration file /etc/named.conf is denoted by a full pathname relative to the sandbox, i.e. in the line above, the file referred to is actually /etc/namedb/etc/named.conf.

The next step is to edit /etc/namedb/etc/named.conf so that named knows which zones to load and where to find them on the disk. There follows a commented example (anything not specifically commented here is no different from the setup for a DNS server not running in a sandbox):

options {
        directory "/";
        named-xfer "/bin/named-xfer";
        version "";     // Don't reveal BIND version
        query-source address * port 53;
};
// ndc control socket
controls {
        unix "/var/run/ndc" perm 0600 owner 0 group 0;
};
// Zones follow:
zone "localhost" IN {
        type master;
        file "master/named.localhost";
        allow-transfer { localhost; };
        notify no;
};
zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "master/localhost.rev";
        allow-transfer { localhost; };
        notify no;
};
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" {
    type master;
    file "master/localhost-v6.rev";
    allow-transfer { localhost; };
    notify no;
};
zone "." IN {
        type hint;
        file "master/named.root";
};
zone "private.example.net" in {
        type master;
        file "master/private.example.net.db";
    allow-transfer { 192.168.10.0/24; };
};
zone "10.168.192.in-addr.arpa" in {
        type slave;
        masters { 192.168.10.2; };
        file "slave/192.168.10.db";
};

After completing the steps above, either reboot your server or restart syslogd(8) and start named(8), making sure to use the new options specified in syslogd_flags and named_flags. You should now be running a sandboxed copy of named!

23.6.9 Security

Although BIND is the most common implementation of DNS, there is always the issue of security. Possible and exploitable security holes are sometimes found.

It is a good idea to read CERT's security advisories and to subscribe to the FreeBSD security notifications mailing list to stay up to date with the current Internet and FreeBSD security issues.

23.6.10 Further Reading

BIND/named manual pages: ndc(8) named(8) named.conf(5)

• Official ISC BIND Page

• BIND FAQ

• O'Reilly DNS and BIND 4th Edition

• RFC1034 - Domain Names - Concepts and Facilities

• RFC1035 - Domain Names - Implementation and Specification