17.9. DNS

Written by Chern Lee , April 12, 2001.

17.9.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 ips, and vice versa. For example, a query for www.freebsd.org will send back a reply for the IP address of The FreeBSD Project's webpage, whereas, a query for ftp.freebsd.org will return the IP of the corresponding ftp machine. Likewise, the opposite can happen. A query for an ip address can resolve its hostname.

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

This document refers to BIND 8.x, as it is the most current, stable version used in FreeBSD.

RFC1034 and RFC1035 dictates the DNS protocol.

Currently, BIND is maintained by the Internet Software Consortium (www.isc.org)

17.9.2. Terminology Used

zone - Each individual domain, subdomain, or 'area' dictated by DNS is considered a zone.

Examples of zones:

named, bind, name server - these are all common names for the BIND name server package within FreeBSD.

resolver - a network process by which a system queries a nameserver for answers

root zone - literally, a '.', refers to the root, or beginning zone. All zones fall under this, as do all files in fall under the root directory. It is the beginning of the Internet zone hierarchy

origin - refers to the point of start for the particular zone

forward dns - mapping of hostnames to ip addresses

reverse dns - the opposite, mapping of ip addresses to hostnames

17.9.3. Reasons to run a name server

17.9.4. How it works

A DNS server in FreeBSD relies on the BIND daemon. This daemon is called 'named' for obvious reasons.

named - the bind daemon

ndc - name daemon control program

/etc/namedb - directory where all the bind information resides

/etc/namedb/named.conf - daemon configuration file

zone files are usually contained within the /etc/namedb directory, and contain the information (query answers from your site) served by your name server.

17.9.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 modifications in your /etc/rc.conf

    named_enable="YES"

To start the daemon manually (after configuring it)

    # ndc start

17.9.6. Configuration files

17.9.6.1. make-localhost

Be sure to

            # cd /etc/namedb
        # sh make-localhost
          

to properly create your local reverse dns zone file in /etc/namedb/localhost.rev.

17.9.6.2. /etc/namedb/named.conf

    // $FreeBSD: doc/zh/big5/handbook/advanced-networking/chapter.sgml,v 1.7 2001/05/22 08:41:07 statue Exp $
    //
    // Refer to the named(8) man 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;
            };
    */
          

Just as the comment says, if you want to benefit from your uplink's cache, you can enable this section of the config file. Normally, your nameserver will recursively query different nameservers until it finds the answer it is looking for. Having this enabled will have it automatically see if your uplink's (or whatever provided) ns has the requested query. If your uplink has a heavily trafficked, fast nameserver, enabling this properly could work to your advantage. 127.0.0.1 will *NOT* work here; change this to the ip of a nameserver at your uplink.

            /*
             * If there is a firewall between you and nameservers 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 "domain.com" {
            type slave;
            file "s/domain.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;
            };
    };
    */
          

These are example slave entries, read below to see more.

For each new domain added to your nameserver, you must add one of these entries to your named.conf

The simplest zone entry, can look like

    zone "foobardomain.org" {
    	type master;
    	file "foorbardomain.org";
    };
          

For a master entry with the zone information within foobardomain.org, or

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

for a slave. Note that slave zones automatically query the listed master (authoritative) name servers for the zone file.

17.9.6.3. Zone files

An example master 'foobardomain.org' (existing within /etc/namedb/foobardomain.org) is as follows:

    $TTL 3600
    
    foobardomain.org. IN SOA ns1.foobardomain.org. admin.foobardomain.org. (
                            5               ; Serial
                            10800           ; Refresh
                            3600            ; Retry
                            604800          ; Expire
                            86400 )         ; Minimum TTL
    
    ; DNS Servers
    @       IN NS           ns1.foobardomain.org.
    @       IN NS           ns2.foobardomain.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.foobardomain.org.
          

Note that every hostname ending in a '.' is an exact hostname, whereas everything without a trailing '.' is referenced to the origin. For example, www is transalated into www + origin. In our ficitious zone file, our origin is foobardomain.org, so www would be www.foobardomain.org.

The format of this file follows:

    recordname      IN recordtype  value

The most commonly used DNS records:

SOA - start of zone authority

NS - an authoritative nameserver

A - A host address

CNAME - the canonical name for an alias

MX - mail exchange

PTR - a domain name pointer (used in reverse dns)

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

foobardomain.org. - the domain name, also the origin for this zone file.

ns1.foobardomain.org. - the primary/authoritative nameserver for this zone

admin.foobardomain.org. - the responsible person for this zone, e-mail address with @ replaced. (admin@foobardomain.org becomes admin.foobardomain.org)

5 - the serial number of the file. this must be incremented each time the zone file is modified. Nowadays, many admins prefer a yyyymmddrr format for the serial number. 2001041002 would mean last modified 04/10/2001, the latter 02 being the second time the zone file has been modified this day. The serial number is important as it alerts slave nameservers for a zone when it is updated.

    @       IN NS           ns1.foobardomain.org.
          

This is an NS entry. Every nameserver that is going to reply authoritatively for the zone must have one of these entries. The @ is seen here could have been 'foobardomain.org.' The @ transalates to the origin.

    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
          

The A record indicates machine names. As seen above, ns1.foobardomain.org would resolve to 3.2.1.2. Again, the origin symbol, @, is used here, thus meaning foobardomain.org would resolve to 3.2.1.30.

    www             IN CNAME        @
          

The canonical name record is usually used for giving aliases to a machine. In the example, www is aliased to the machine addressed to the origin, or foobardomain.org (3.2.1.30). CNAMEs can be used to provide alias hostnames, or round robin one hostname among multiple machines.

    @               IN MX   10      mail.foobardomain.org.
          

The MX record indictes which mail servers are responsible for handling incoming mail for the zone. mail.foobardomain.org is the hostname of the mail server, and 10 being the priority of that mailserver.

One can have several mailservers, with priorities of 3, 2, 1. A mail server attempting to deliver to foobardomain.org would first try the highest priority MX, then the second highest, etc, until the mail can be properly delivered.

For in-addr.arpa zone files (reverse dns), the same format is used, except with PTR entries instead of A or CNAME.

    $TTL 3600
    
    1.2.3.in-addr.arpa. IN SOA ns1.foobardomain.org. admin.foobardomain.org. (
                            5               ; Serial
                            10800           ; Refresh
                            3600            ; Retry
                            604800          ; Expire
                            3600 )          ; Minimum
    
    @       IN NS   ns1.foobardomain.org.
    @       IN NS   ns2.foobardomain.org.
    
    2       IN PTR  ns1.foobardomain.org.
    3       IN PTR  ns2.foobardomain.org.
    10      IN PTR  mail.foobardomain.org.
    30      IN PTR  foobardomain.org. 
          

This file gives the proper ip to hostname mappings of our above ficticious domain.

17.9.7. Caching Name Server

A caching nameserver is simply a nameserver 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.

17.9.8. How to use the nameserver

If setup properly, the nameserver should be accessible through the network and locally. /etc/resolv.conf must contain a nameserver entry with the local ip so it will query the local name server first.

To access it over the network, the machine must have the nameserver's ip set properly in its own nameserver configuration options.

17.9.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 subscribe to CERT and freebsd-announce to stay up to date with the current Internet and FreeBSD security issues.

If a problem arises, keeping your sources up to date and having a fresh build of named can't hurt.

17.9.10. Further Reading

ndc(8) named(8) named.conf(5)

Official ISC BIND Page http://www.isc.org/products/BIND/

BIND FAQ http://www.nominum.com/resources/faqs/bind-faqs.html

O'Reilly DNS and BIND 4th Edition

RFC1034 - Domain Names - Concepts and Facilities

RFC1035 - Domain Names - Implementation and Specification