Hour 18 Running Your Own Name Server

A common task among Unix system administrators is setting up and running a domain name system (DNS) server. Though we’re used to thinking of Web sites, e-mail recipient systems, and other network information as specific names, the Internet actually uses unique numbers. The DNS server system maps names to numbers.

When you type a URL into your Web browser, for example, it first contacts your local DNS server asking for the IP address of the Web host you are requesting. If your local DNS server does not know the IP address, it will then forward the request to another DNS server, often one of the root DNS servers¹. The root server typically won’t answer the query, but will instead forward you along, reporting the IP address of the authoritative DNS server-for the domain you are requesting. Your local DNS server then contacts this DNS server, and finally receives the correct IP address.

¹There are 13 root servers scattered around the world. They all contain the IP addresses of the name servers that are registered with a particular domain.

In this hour, we’ll have a tour of the DNS system, with specific emphasis on how to maintain a DNS server on your Unix systems.

In this hour, you’ll learn about

• Working with BIND and zone files

• Configuring named, the name server daemon

• Working with rndc, the best DNS admin tool

• Testing DNS installations

The Berkeley Internet Name Domain Package

To manage a DNS database, systems running as DNS servers often run the Berkeley Internet Name Domain (BIND) system, a powerful and flexible DNS server. RedHat Linux 7.2 ships with BIND version 9. Indeed, it turns out that early versions of BIND are notorious for having security problems, so if you’re going to start running a DNS server, it’s a smart idea to upgrade to the latest release. Of course, as with any software that interacts with the outside network, it’s always a good idea to keep BIND up-to-date with the latest security patches and bug repairs.

Task 18.1: Exploring BIND and Zone Files

It is important to note that named only needs to be run if you are going to be providing authoritative name services for one or more domains. What’s an authoritative name? It’s the official host on the Internet that’s authorized by the domain name record to answer DNS queries.

1. To see what DNS servers are the authoritative name servers for a given domain, use the whois command:

    $ whois intuitive.com

    Whois Server Version 1.3

    Domain names in the .com, .net, and .org domains can now be registered
    with many different competing registrars. Go to http://www.internic.net
    for detailed information.

       Domain Name: INTUITIVE.COM
       Registrar: NETWORK SOLUTIONS, INC.
       Whois Server: whois.networksolutions.com
       Referral URL: http://www.networksolutions.com
       Name Server: NS11A.VERIO-WEB.COM
       Name Server: NS11B.VERIO-WEB.COM
       Updated Date: 05-nov-2001

    >>> Last update of whois database: Fri, 19 Apr 2002 05:03:06 EDT <<<

    The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and
    Registrars.

You can see in this record that the authoritative name servers are NS11A.VERIO-WEB.COM and NS11B.VERIO-WEB.COM. But where does the information that these are the authoritative name servers for this specific domain come from? A DNS server…

2. To be an authoritative name server, the most important part of the configuration is to have a zone file for each domain.

Zone files describe the domain you are providing name services for, and the individual hosts that have been given names. Each domain will usually contain two zone files, one for normal lookups and one for reverse lookups (converting an IP address to its fully qualified domain name).

Zone files typically contain one or more lines of directives, followed by multiple lines listing individual resource types and their hostname and IP address pairs. Here’s a typical entry, the one that serves as the statement or zone of authority (SOA) for intuitive.com:

    # cat /var/named/intuitive.com.zone
    $ORIGIN intuitive.com.
    $TTL 86400

There’s a lot in this zone file, so let’s take it one step at a time. First off, notice that the very first line has a trailing dot after the domain name (for example, intuitive.com.). It turns out that this trailing dot is very important, and omitting it is a common mistake for DNS administrators: If you forget, then the hostname is automatically prepended, which is usually wrong.

The second line has the Time-To-Live (TTL) directive, and it’s in units of seconds: 86,400 = 24 hours. Think of this as the expiration date: Once the TTL has expired, any DNS cache is required to request a fresh copy of the data.

3. The remainder of the zone file is comprised of resource records. The first resource record is a Statement Of Authority (SOA), and it has its own TTL, administrative address associated with the domain record (albeit with the usual @ replaced with a dot), and a number of configuration parameters, as detailed in Table 18.1.

Table 18.1 Statement of Authority Fields in a Zone File

Notice that the zone file inherently includes the concept of having a secondary, as well as a primary, domain server. This is a smart fail-safe architecture: By having multiple servers able to act authoritatively, users are less likely to have a DNS query fail if the primary server is offline. However, having multiple primary servers leads to a puzzle that this also solves—which of the multiple servers ″owns″ the domain name record? That’s what all the refresh, expiry, and other values specify—they tell authoritative, but nonprimary, name servers how to interact with the primary for this specific domain name.

4. All the subsequent lines in the zone file specify explicit types of domain information. Notice the column that has NS, MX, A, and CNAME values—those indicate whether the specified record is a name server, mail exchange, address queries, or alternate (canonical) name, respectively.

For example, we can see explicitly that ns11a.verio-web.com and ns11b.verio-web.com are the name servers (NS) for this domain, and that e-mail receipt queries resolve to mail-fwd.verio-web.com. The second MX record, explicitly listing www.intuitive.com, allows mail sent to a user @www.intuitive.com to resolve properly and drop into the correct mailbox.

Finally, there is a set of resource records that actually map domain and subdomain names to explicit IP addresses. Here we can see that intuitive.com and the host ftp, smtp, and www are assigned the same IP address as the main domain record, but urlwire is a completely different IP address. This correctly implies that Web and mail queries to urlwire.intuitive.com are handled by a different server.

The very last record demonstrates a helpful shorthand available in zone files: A CNAME record is essentially an alias, so the line

    staging       86400 IN   CNAME    urlwire

indicates that queries for staging.intuitive.com should be answered exactly the same as queries for urlwire.intuitive.com.

Commonly, www subdomains are aliases to the main Web server through a CNAME in just this fashion. Indeed, the zone file would be just as valid if the last few lines were written as

The eagle-eyed among you will have noticed that fully qualified domain names (FQDNs in DNS parlance: a domain that includes all elements—intuitive.com—versus the unqualified domain name www) always have that trailing dot, whereas subdomains do not. It’s important to keep this straight, so as not to corrupt your DNS system.

5. Before we leave the discussion about zone files, let’s have a peek at a different type, a reverse lookup zone file:

Much of this is the same as the earlier zone file, including the TTL, NS, and SOA records. The difference lies in the very last line, which lists the fourth octet of the domain IP address (for example, 91).

Notice that an inherent limitation of zone files is that we can only list one subnet per file, so a separate reverse lookup zone file is required to permit a reverse lookup for the staging.intuitive.com domain name (for example, the 63.101.93.x subnet).

Writing zone files from scratch is quite confusing, and there are few tools available to help. One that might offer some respite from the potential headache that this represents is available at www.dnstools.com, and it’s well worth exploring. Unfortunately, it’s only available for Linux as of this writing. Mac OS X users might find DNSetup a useful, albeit less powerful, alternative tool (homepage.mac.com/dnsetup/).

Configuring named

The zone files that we’ve explored up to this point are the data files that are fed to the actual DNS name server, named. The named program runs by reading a named.conf file, which is typically found in /etc/. The next step in our journey is to dig into this configuration file and see how it ties in with the individual zone files.

Task 18.2: Configuring the Name Server named

The named daemon reads the /etc/named.conf file to identify which zone files it needs to load. All options and statements within the configuration file are terminated with a semicolon.

1. To start, let’s check out the named.conf file:

    # cat/etc/named.conf
    options {
            directory ″/var/named″;
            /*
             * 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;
    };

    controls {
            inet 127.0.0.1 allow { localhost; } keys { rndckey; };
    };
    zone ″.″ IN {
            type hint;
            file ″named.ca″;
    };

    zone ″localhost″ IN {
            type master;
            file ″localhost.zone″;
            allow-update { none; };
    };

    zone ″0.0.127.in-addr.arpa″ IN {
            type master;
            file ″named.local″;
            allow-update { none; };
    };

    zone ″intuitive.com″ IN {
            type master;
            file ″intuitive.com.zone″;
            allow-update { none; };
    };

    zone ″20.58.161.in-addr.arpa″ IN {
            type master;
            file ″20.58.161.in-addr.arpa.zone″;
            allow-update { none; };
    };

    include ″/etc/rndc.key″;

There’s quite a bit in this file, but a quick glance reveals that there are a few control statements at the top, then a recurring zone block, and a final include at the bottom. Don’t be too intimidated!

The first statement we have is options, which is used to control the assorted options available to named. In this configuration, the only option set is directory, which informs named where to look for the zone files.

There’s a very helpful administrative utility called rndc, and the next statement in the configuration file specifies who can make changes to named while it’s running. The controls statement indicates that named is only monitoring the local loopback address for localhost, and that connections must be verified using the secret key rndckey (defined in the included file at the end).

2. The remainder of the configuration file contains blocks of zone file inclusion statements (except the last line, which we’ll talk about shortly).

The first zone specifies the root of the DNS tree with .. These are the root servers for the entire Internet. When named receives a request for a host it doesn’t know about, it will contact one of the root servers asking for the DNS server registered with the domain name.

After the name of the zone, the class is required. The class is always IN for Internet. The different options for each zone are specified within its block, delimited by open and closed curly brackets. Our first option is the type of zone being specified. Just about all of them will be master, but the root domain shows up as hint. No other zone block should specify hint if things are configured properly.

The next option is the name of the zone file, and you can see why a standard naming scheme is quite helpful at this point. Oddly, the root domain has a zone file with the default name of named.ca. It is located in /var/named, as expected, so you can easily peek inside this 83-line default zone file if you’d like.

The next four zones work together as pairs, a forward-looking (name-to-IP number) and reverse looking (IP number-to-name) zone for each domain.

3. Let’s look at the next two zones together, as they describe the loopback interface:

    zone ″localhost″ IN {
            type master;
            file ″localhost.zone″;
            allow-update { none; };
    };

    zone ″0.0.127.in-addr.arpa″ IN {
            type master;
            file ″named.local″;
            allow-update { none; };
    };

The named zone goes first by convention, and it’s important to have the name specified match the $ORIGIN value in the zone file itself:

    # grep ORIGIN /var/named/localhost.zone
    $ORIGIN localhost.

Again, notice where there’s a trailing dot and where there isn’t. It is just as important to omit the trailing dots in the named.conf file as it is to ensure that they’re properly specified in the individual zone files.

There are various types of zones that can be specified in the configuration file, but as we are hoping to be the authoritative name server for the specified domains, we want to be the master. The other possibility is slave, in which case we act as a backup authoritative name server, but get the master data from another more authoritative server.

Finally, the block specifies the name of the zone file, followed by an optional list of hosts that have the authority to update this zone, if any.

The last entry in the named.conf file is an include statement, which causes named to include the contents of the specified file as if it were part of the named.conf file itself. Why do this? To enable the system administrator to hide sensitive data in a separate file with permissions that prevent unauthorized access.

In our example, named loads a file containing the secret key for the named administrative utility rndc (explained later this hour).

4. Because you need to have at least two name servers online for any given domain name, being able to have slave zone definition blocks is a boon. Without it, you’d have to manually distribute all the zone files to multiple systems and/or edit two or more files for each change required.

A sample slave entry in the named.conf file on a secondary, or backup DNS server, would look like this:

    zone ″intuitive.com″ IN {
            type slave;
            file ″intuitive.com.zone″;
            masters { 161.58.20.91; };
    };

This zone block tells named to contact host 161.58.20.91 for the zone configuration information, and to store it in a file named intuitive.com.zone.

The named.conf file and the individual zone files stored in /var/named combine to let a system administrator create a fully functional domain name server for anywhere from two or three to thousands of domain names.

Working with rndc

The named daemon only reads its configuration files on startup, which implies that each time you modify a zone file or the named.conf file you should restart the server. Rather than starting and stopping each time a change is made, however, you should use the remote name daemon control (rndc) program.

Task 18.3: Learning rndc

There are a variety of useful administrative tasks that can be accomplished with rndc, but let’s just consider a couple of the most basic–you can read the rndc man page for more information if you’re curious or need additional capabilities.

1. The most common operation is to force a reload of the configuration files. This is accomplished using the reload command:

    # rndc reload
    #

If you have a lot of zone files and want to save time on the reload, explicitly specify reconfig instead and named will only scan the named.conf file and any new zone files it finds. Again, there’s no output unless an error is encountered:

    # rndc reconfig
    #

2. Other common rndc options that you might find useful are listed in Table 18.2.

Table 18.2 Useful rndc Commands

rndc is only used with BIND version 9, and carries most of the same commands that were available in ndc, the named daemon control program from previous versions of BIND.

3. The rndc command has its own configuration file, /etc/rndc.conf. The default is probably quite sufficient, particularly because the controls statement in named.conf enables you to state who is allowed to send commands to named using rndc.

    # cat /etc/rndc.conf
    options {
            default-server localhost;
            default-key    ″key″;
    };

    server localhost {
            key     ″rndckey″;
    };

    key ″rndckey″ {
            algorithm      hmac-md5;
            secret
    ″k0sYAWycZNcPVfLojkdnKWkgqYJsbNCtR0GyXYkldQehDcurizoHtQbFhqNp″;
    };

4. Before you’re done with rndc, it’s quite helpful to run the utility named-checkzone to verify the syntax of each zone file. To use this utility, specify a zone name and zone file:

    # /etc/named-checkzone intuitive.com /var/named/intuitive.com.zone

You could also drop this into a loop, as in the following:

    cd /var/named
    for name in *
    do
      domain=″‘echo $name | sed ′s/.zone//′′″
      echo ″Domain $domain:″
      /etc/named-checkzone $domain /var/named/$name
    done

A simple utility, the rndc command is critical to effective management of named and your local name server.

Testing DNS Setups

Now that you have your configuration and zone files straight, it’s time to test it and make sure everything is copacetic.

In the old days, there was a great utility called nslookup that offered a simple way to interact with name servers. In the last few years, nslookup has been put out to the proverbial pasture and replaced with two new tools, dig and host.

Task 18.4: Testing with dig and host

Of the two tools, you’ll doubtless find dig (the Domain Information Groper) the most useful, but let’s look at both of them and see what they can offer.

1. In its basic form, dig just needs a domain name to retrieve information:

If you get back something that looks similar to this, everything is working fine with your configuration. If not, go back and double-check your settings.

2. The fourth line of the output gives us a status code status: NOERROR telling us that our query was completed successfully. Line five gives us some stats: how many queries, answers, authorities, and additional information was found for the specified domain.

The next lines are broken up into sections detailing the question asked, the answer found, the authority providing the answer, and any additional information.

We asked the simple question, ″Who is intuitive.com?″ The answer is IP address 161.58.20.91. The authority answering the question is the two name servers ns11a.verio-web.com and ns11b.verio-web.com. And finally, the additional section gives us the IP address of ns11b.verio-web.com.

3. This was a simple example to ensure named responds to requests, but clearly it didn’t return all the information in our zone file.

How can we see it all? By asking for a zone transfer. The wrinkle is that you can only request a zone transfer from the authoritative server, whether it’s an NS or SOA. The solution is to ask dig for it explicitly:

    # dig intuitive.com soa
    ; <<>> DiG 9.1.3 <<>> intuitive.com soa
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19035
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

    ;; QUESTION SECTION:
    ;intuitive.com.                IN      SOA

    ;; ANSWER SECTION:
    intuitive.com.       27849   IN      SOA     feed11.verio-web.com. hostmaster
    .verio-web.com. 2001121419 7200 3600 604800 86400

    ;; AUTHORITY SECTION:
    intuitive.com.         79548   IN      NS      ns11b.verio-web.com.
    intuitive.com.         79548   IN      NS      ns11a.verio-web.com.

    ;; ADDITIONAL SECTION:
    ns11b.verio-web.com.   149073  IN      A       161.58.148.98

    ;; Query time: 5 msec
    ;; SERVER: 192.168.1.250#53(192.168.1.250)
    ;; WHEN: Fri Apr 12 01:31:03 2002
    ;; MSG SIZE rcvd: 151

Now we can ask ns11b.verio-web.com to give us all records for intuitive.com. There are quite a few different queries you can perform, but a zone transfer is specified with axfr:

    # dig @ns11a.verio-web.com intuitive.com axfr

    ; <<>> DiG 9.1.3 <<>> @ns11a.verio-web.com intuitive.com axfr
    ;; global options:  printcmd
    intuitive.com.         86400   IN      SOA     feed11.verio-web.com. hostmaster
    .verio-web.com. 2001121419 7200 3600 604800 86400
    intuitive.com.         86400   IN      NS      ns11a.verio-web.com.
    intuitive.com.         86400   IN      NS      ns11b.verio-web.com.
    intuitive.com.         86400   IN      MX      50 mail-fwd.verio-web.com.
    intuitive.com.         86400   IN      A       161.58.20.91
    ftp.intuitive.com.     86400   IN      A       161.58.20.91
    smtp.intuitive.com.    86400   IN      A       161.58.20.91
    www.intuitive.com.     86400   IN      MX      50 mail-fwd.verio-web.com.
    www.intuitive.com.     86400   IN      A       161.58.20.91
    urlwire.intuitive.com. 86400   IN      A       63.101.93.250
    staging.intuitive.com. 86400   IN      A       63.101.93.250
    intuitive.com.         86400   IN      SOA     feed11.verio-web.com. hostmaster
    .verio-web.com. 2001121419 7200 3600 604800 86400
    ;; Query time: 169 msec
    ;; SERVER: 161.58.148.62#53(feed11.verio-web.com)
    ;; WHEN: Fri Apr 12 01:38:34 2002
    ;; XFR size: 13 records

4. To ask for a specific type of query, specify any one of a (network address), any (all information about the domain), mx (mail exchange), ns (name servers), soa (the zone of authority record), hinfo (host info), axfr (zone transfer), or txt (arbitrary strings of text).

Knowing this, it’s interesting to query a busy, well-known server to see how it’s set up. For example, AOL’s mail exchange records should prove interesting:

5. Another utility used to check DNS records is host. In its simplest form, host converts back and forth between a domain name and its IP address:

    # host intuitive.com
    intuitive.com. has address 161.58.20.91
    # host 161.58.20.91
    91.20.58.161.in-addr.arpa. domain name pointer www.intuitive.com.

If we add the -v (verbose) flag to the command, the output is very similar to dig:

    $ host -v intuitive.com
    Trying ″intuitive.com.″
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22099
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

    ;; QUESTION SECTION:
    ;intuitive.com.                   IN      A

    ;; ANSWER SECTION:
    intuitive.com.            26740   IN      A       161.58.20.91

    ;; AUTHORITY SECTION:
    intuitive.com.            78646   IN      NS      ns11a.verio-web.com.
    intuitive.com.            78646   IN      NS      ns11b.verio-web.com.

    ;; ADDITIONAL SECTION:
    ns11b.verio-web.com.      148171  IN      A       161.58.148.98

    Received 113 bytes from 192.168.1.250#53 in 5 ms

Using the -l (list) command is the same as asking for zone (axfr) information using dig, but host presents the information in a friendlier format. You still need to specify an authoritative server for this to work:

    # host -l intuitive.com ns11a.verio-web.com
    Using domain server:
    Name: feed11.verio-web.com
    Address: 161.58.148.62#53
    Aliases:

    intuitive.com. SOA feed11.verio-web.com. hostmaster.verio-web.com.
       2001121419 7200 3600 604800 86400
    Using domain server:
    Name: feed11.verio-web.com
    Address: 161.58.148.62#53
    Aliases:

    intuitive.com. name server ns11a.verio-web.com.
    Using domain server:
    Name: feed11.verio-web.com
    Address: 161.58.148.62#53
    Aliases:

    intuitive.com. name server ns11b.verio-web.com.
    Using domain server:
    Name: feed11.verio-web.com
    Address: 161.58.148.62#53
    Aliases:

    intuitive.com. mail is handled by 50 mail-fwd.verio-web.com.
    Using domain server:
    Name: feed11.verio-web.com
    Address: 161.58.148.62#53
    Aliases:

    intuitive.com. has address 161.58.20.91
    Using domain server:
    Name: feed11.verio-web.com
    Address: 161.58.148.62#53
    Aliases:

    ftp.intuitive.com. has address 161.58.20.91
    Using domain server:
    Name: feed11.verio-web.com
    Address: 161.58.148.62#53
    Aliases:

    smtp.intuitive.com. has address 161.58.20.91
    Using domain server:
    Using domain server:
    Name: feed11.verio-web.com
    Address: 161.58.148.62#53
    Aliases:

    www.intuitive.com. mail is handled by 50 mail-fwd.verio-web.com.
    Using domain server:
    Name: feed11.verio-web.com
    Address: 161.58.148.62#53
    Aliases:

    www.intuitive.com. has address 161.58.20.91
    Using domain server:
    Name: feed11.verio-web.com
    Address: 161.58.148.62#53
    Aliases:

    urlwire.intuitive.com. has address 63.101.93.250
    Using domain server:
    Name: feed11.verio-web.com
    Address: 161.58.148.62#53
    Aliases:

    staging.intuitive.com. has address 63.101.93.250
    Using domain server:
    Name: feed11.verio-web.com
    Address: 161.58.148.62#53
    Aliases:
    intuitive.com. SOA feed11.verio-web.com. hostmaster.verio-web.com.
    2001121419 7200 3600 604800 86400

The two utilities dig and host are similar to each other, and both provide the same information. Because of the breadth of options that are available with dig, it can be more powerful than host, but host is a good tool to use because of its simplicity.

Summary

This hour has focused on the basic concepts and configuration of a domain name server using the popular Berkeley BIND package. We’ve explored zone files, the named.conf file, and discussed master and slave servers. In addition, we explored various useful utilities that are quite useful whether you’re running a name server or not. In particular, host offers a helpful reverse-IP lookup utility that can make reading through log files much more informative.

Q&A

Q I want to control my domain name record, but not run a BIND server. Am I out of luck?

A A year or two ago the answer would have been ″yes, you’re outta luck,″ but there are a number of different Web-accessible domain name servers that enable you to easily manage your own DNS records without the hassle of BIND, zone files, and so on. I use one myself: http://www.mydomain.com/.

Q What are the numbers just before the domain names in MX records? A search for the MX records for AOL, for example, prefaced each MX server with 15. What does it mean?

A The number is the priority value associated with each of the MX servers for that domain. The lower the number, the higher the priority. If there are multiple servers with the same priority, the system load-balances by randomly picking one as the recipient system.

Workshop

Quiz

1. What’s the main reason for updating your version of BIND?

2. What happens if you omit the trailing dots on domain names in the ORIGIN section of a zone file?

3. What would happen if a TTL for a master record was set to 60? Would that be good or bad?

4. What should you always remember to do when you edit a zone file?

5. Why is it dangerous to let other hosts update your zone configuration files through rndc?

6. What very important thing happens if you use the command rndc stop that doesn’t occur with rndc halt?

Answers

1. In a word: security.

2. ORIGIN names that lack a trailing dot have the hostname automatically prefaced, changing the intent of the statement in the zone file in most cases.

3. Setting the TTL too low will cause the network to saturate, as DNS caches keep asking for new authoritative records again and again. It’d definitely be bad.

4. Update or increment the serial number in the zone file.

5. See Answer #1.

6. The stop command saves any changes to the zone information by rewriting the master files. The halt command does not change the master files.

A name server is a single Internet service, as is a Web server (covered in the last two hours of this book). The next hour will focus on a variety of different Internet services, including a discussion of how to enable or disable ftp access, and an exploration of the useful telnet utility.