Understanding DNS
Configuring DNS is no easy task. Emmett's here to walk you through it, from setting up the resolver to understanding how zone files and resource records work.
It's practically impossible to exaggerate the importance of the Domain Name System (DNS) as networks grow to include hosts of all sorts. And as its importance grows, so does the need to understand how to configure it.
You configure DNS by using a number of configuration files. The exact set of files depends on whether you're running a name server and, if so, the type of name server: caching or primary. You'll need some configuration files whether you run a name server or not.
Configuring the Resolver
You don't need a name server running on your system to use the DNS clients (dig and host). You can use them to query your domain's name server. Typically, your ISP provides you with this information. You have to list the IP addresses of these name servers in the /etc/resolv.conf file, which the resolver library reads to determine how to resolve host names. The format of this file is
domain your-domain.com
search your-domain.com
nameserver A.B.C.D
nameserver X.Y.Z.W
where A.B.C.D and X.Y.Z.W are the IP addresses (dot-separated numeric addresses, such as 192.168.0.1) of the primary and secondary name servers that your ISP provides you.
The domain line lists the local domain name. The search line specifies the domains on which a host name is searched first (usually, you put your own domain in the search line). The domain listed on the search line is appended to any host name before the resolver library tries to resolve it. For example, if you look for a host named mailhost, the resolver library first tries mailhost.your-domain.com; if that fails, it tries mailhost. The search line applies to any host name that you try to access. For example, if you're trying to access www.redhat.com, the resolver first tries www.redhat.com.your-domain.com and then www.redhat.com.
Another important configuration file is /etc/host.conf, which tells the resolver what to do when attempting to resolve a host name. A typical /etc/host/conf file contains the following line:
order hosts,bind
This command tells the resolver to consult the /etc/hosts file first and, if that fails, to query the name server listed in the /etc/resolv.conf file. The /etc/hosts file usually lists any local host names and their IP addresses. Here's a typical line from the /etc/hosts file:
127.0.0.1 lnbp200 localhost.localdomain localhost
This line says that the IP address 127.0.0.1 is assigned to the host names lnbp200, localhost.localdomain and localhost. In the latest version of the Linux kernel -- the one that uses GNU C Library version 2 (glibc 2) or later -- the name service switch (NSS) file, /etc/nsswitch.conf, controls how services such as the resolver library, NIS, NIS+ and local files such as /etc/hosts and /etc/shadow interact. For example, the following hosts entry in the /etc/nsswitch.conf file specifies that the resolver library first try the /etc/hosts file, then try NIS+, and finally try DNS:
hosts: files nisplus dns
To find more about the /etc/nsswitch.conf file and what it does, type man nsswitch.conf in a terminal window.
Configuring a Caching Name Server
A simple but useful name server is one that finds answers to host name queries (by using other name servers) and then remembers the answer (by saving it in a cache) for the next time you need it. This caching name server can shorten the time it takes to access hosts you've accessed recently; the answer is already in the cache.
When you install BIND, the configuration files for a caching name server are also installed. That means you can start running the caching name server without much work on your part. This section describes the configuration files and what you have to do to start the caching name server.
The /etc/named.conf File
The first configuration file you need is /etc/named.conf. (Actually, that's the name in Fedora and SUSE; in Debian, MEPIS, Ubuntu and Xandros, the BIND configuration file is called /etc/bind/named.conf.) The named server reads this configuration file when it starts. You already have this file if you installed BIND. Listing 1 shows a /etc/named.conf file from Fedora.
Comments are C-style (/* ... */) or C++-style (starting with //). The file contains block statements enclosed in curly braces ({...}) and terminated by a semicolon (;). A block statement in turn contains other statements, each ending with a semicolon.
This /etc/named.conf file begins with an options block statement with a number of option statements. The directory option statement tells named where to look for all other files that appear on file lines in the configuration file. In this case, named looks for the files in the /var/named directory. Note that in SUSE, the directory option in /etc/named.conf refers to the /var/lib/named directory, which means that all other BIND configuration files are in /var/lib/named. In Debian and Xandros, the configuration files are explicitly specified to be in the /etc/bind directory.
The controls statement in /etc/named.conf contains security information so that the remote name daemon control (rndc) command can connect to the named service at port 953 and interact with named. In this case, the controls statement contains the following line:
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
This command says that rndc can connect from localhost with the key named rndc. (The file /etc/rndc.key defines the key and the encryption algorithm to be used.) The rndc utility is a successor to the older ndc (name daemon controller) utility used to control the named server by sending it messages over a special control channel, a TCP port where named listens for messages. The rndc utility uses a cryptographic key to authenticate itself to the named server. The named server has the same cryptographic key so that it can decode the authentication information sent by rndc.
After the options statement, the /etc/named.conf file contains several zone statements, each enclosed in curly braces and terminated by a semicolon. Each zone statement defines a zone. The first zone is named . (root zone); it's a hint zone that specifies the root name servers. (When the DNS server starts, it uses the hint zone to find a root name server and get the most recent list of root name servers.)
The next two zone statements in /etc/named.conf are master zones, which are the master copies of data for a domain. The syntax for a master zone statement for an Internet class zone (indicated by the IN keyword) is as follows:
zone "zone-name" IN {
type master;
file "zone-file";
[...other optional statements...]
};
The zone-name is the name of the zone, and zone-file is the zone file that contains the resource records (RR) -- the database entries -- for that zone. The next two sections describe zone file formats and RR formats.
Zone File Formats
The zone file typically starts with a number of directives, each of which begins with a dollar sign ($) followed by a keyword. Two commonly used directives are $TTL and $ORIGIN. For example, the line
$TTL 86400
uses the $TTL directive to set the default Time To Live (TTL) for subsequent records with undefined TTLs. The value is in seconds, and the valid TTLs are in the range 0 to 2147483647 seconds. In this case, the directive sets the default TTL as 86,400 seconds (or one day).
The $ORIGIN directive sets the domain name that's appended to any unqualified records. For example, the following $ORIGIN directive sets the domain name to localhost:
$ORIGIN localhost.
If there is no $ORIGIN directive, the initial $ORIGIN is the same as the zone name that comes after the zone keyword in the /etc/named.conf file. After the directives, the zone file contains one or more RRs. These records follow a specific format, which are outlined in the next section.
Resource Record (RR) Formats
You have to understand the format of the RRs before you can understand and intelligently work with zone files. Each RR has the following format (the optional fields are shown in square brackets):
[domain] [ttl] [class] type data [;comment]
The fields are separated by Tabs or spaces and may contain some special characters, such as an @ symbol for the domain and a semicolon (;) to indicate the start of a comment. The first field, which must begin at the first character of the line, identifies the domain. You can use the @ symbol to use the current $ORIGIN for the domain name for this record. If you have multiple records for the same domain name, leave the first field blank.
The optional TTL field specifies the Time To Live -- the duration for which the data can be cached and considered valid. You can specify the duration in one of the following formats:
- N, where N is a number meaning N seconds.
- NW, where N is a number meaning N weeks.
- ND, where N is a number meaning N days.
- NH, where N is a number meaning N hours.
- NM, where N is a number meaning N minutes.
- NS, where N is a number meaning N seconds.
The letters W, D, H, M and S can also be in lowercase. Thus, you can write 86,400 or 1D (or 1d) to indicate a duration of one day. You can also combine these to specify more precise durations, such as 5w6d16h to indicate five weeks, six days and 16 hours. The class field specifies the network type. The most commonly used value for this field is IN for Internet.
Next in the RR is the type field, which denotes the type of record (such as SOA, NS, A or PTR). Table 18-1 in Naba Barkakati's Red Hat Fedora Linux Secrets helpfully lists the DNS RR types. The data field comes next, and that depends on the type field.
Read the RRs in the zone files -- at least the ones of type SOA, NS, A, PTR and MX, which are some of the most commonly used. (You'll find the zone files in the /etc/bind directory in Debian and Xandros, the /var/named directory in Fedora, and the /var/lib/named directory in SUSE.)
Next, there's a brief description of these records, illustrating each record type through an example.
A typical SOA record has the following format:
@ 1D IN SOA @ root (
42 ; serial
3H ; refresh -- 3 hours
15M ; retry –- 15 minutes
1W ; expiry -- 1 week
1D ) ; minimum -- 1 day
The first field specifies the domain as an @, which means the current domain (by default, the zone name, as shown in the /etc/named.conf file). The next field specifies a TTL of one day for this record. The class field is set to IN, which means the record is for Internet. The type field specifies the record type as SOA. The rest of the fields constitute the data for the SOA record. The data includes the name of the primary name server (in this case, @, or the current domain), the e-mail address of the technical contact and five different times enclosed in parentheses.
The NS record specifies the authoritative name servers for a zone. A typical NS record looks like this:
. 3600000 IN NS A.ROOT-SERVERS.NET.
In this case, the NS record lists the authoritative name server for the root zone. (Notice that the name of the first field is a single dot.) The TTL field specifies that the record is to be valid for 1,000 hours (360,0000 seconds). The class is IN, for Internet, and the record type is NS. The final field lists the name of the name server (A.ROOT-SERVERS.NET.), which ends with a dot.
An A record specifies the address corresponding to a name. For example, the following A record shows the address of A.ROOT-SERVERS.NET. as 198.41.0.4:
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
In this case, the network class isn't specified because the field is optional, and the default is IN.
PTR records are used for reverse mapping -- converting an address to a name. Consider the following example:
1 IN PTR localhost.
This record comes from a file for a zone named 0.0.127.in-addr.arpa. Therefore, this record says that the name associated with the address 127.0.0.1 is localhost.
An MX record specifies the name of a host that accepts mail on behalf of a specific domain. For example, here's a typical MX record:
Server7 IN MX 10 mailhub.lnbsoft.com.
This record says that mail addressed to the host named server7 in the current domain is sent to mailhub.lnbsoft.com. (This host is called a mail exchanger.) The number 10 is the preference value. For a list of multiple MX records with different preference values, the ones with lower preference values are tried first.
Armed with this bit of information about RRs, you can go through the zone files for the caching name server.
The Root Zone File
Information about the 13 root name servers is in the zone file referenced in the zone statement for the root zone in the /etc/named.conf file. (In Fedora, the root zone file is /var/named/named.ca; in Debian, MEPIS, Ubuntu and Xandros, it's /etc/bind/db.root; and in SUSE, it's /var/lib/named/root.hint.) Listing 2 shows the root zone file, which contains NS and A RRs that specify the names of authoritative name servers and their addresses for the root zone, indicated by the . in the first field of each NS record.
The comment lines in the file begin with a semicolon. These comments give you hints about the location of the root name servers. There are 13 root name servers for the Internet; most root servers are located in the U.S. This file is a necessity for any name server because the name server has to be able to reach at least one root name server.
The localhost.zone File
The /etc/named.conf file includes a zone statement for the localhost zone that specifies the zone file as localhost.zone. That file is located in the /var/named directory in Fedora, in the /var/local/named directory in SUSE, and in /etc/bind/db.local in Debian and Xandros. Here's a listing of what the localhost.zone file contains:
$TTL 86400
$ORIGIN localhost.
@ 1D IN SOA @ root (
42 ; serial (d. adams)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
1D IN NS @
1D IN A 127.0.0.1
This zone file starts with a $TTL directive that sets the default TTL to one day (86,400 seconds) for subsequent records with undefined TTLs. Next, a $ORIGIN directive sets the domain name to localhost.
After these two directives, the localhost.zone file contains three RRs: a SOA record, an NS record and an A record. The SOA and NS records specify localhost as the primary authoritative name server for the zone. The A record specifies the address of localhost as 127.0.0.1.
The Zone File for Reverse-Mapping 127.0.0.1
The third zone statement in the /etc/named.conf file specifies a reverse-mapping zone named 0.0.127.in-addr.arpa. For this zone, the zone file is /var/named/named.local in Fedora, /var/lib/named/127.0.0.zone in SUSE, and /etc/bind/db.127 in Debian, MEPIS, Ubuntu and Xandros. This zone file contains the following:
$TTL 86400
@ IN SOA localhost. root.localhost. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS localhost.
1 IN PTR localhost.
The SOA and NS records specify localhost as the primary name server. The PTR record specifies localhost as the name corresponding to the address 127.0.0.1. The SOA record also shows root.localhost. as the e-mail address of the technical contact for the domain. Note that the DNS zone files use a user.host. (notice the ending period) format for the e-mail address. When sending any e-mail to the contact, you have to replace the first dot with an @ and remove the final dot.
Caching Name Server: Startup and Test
After you've studied the configuration files for the caching name server, you can start the name server and see it in operation. The way you start the name server varies by distribution. To start the name server, log in as root and type /etc/init.d/named start in Fedora and SUSE. To ensure that the name server starts every time you reboot the system, type chkconfig --level 35 named on in Fedora and SUSE. In Debian, MEPIS, Ubuntu and Xandros, type /etc/init.d/bind9 start to start the name server.
The name server writes diagnostic log messages in the /var/log/messages file. After you start named, you can check the log messages by opening /var/log/messages in a text editor. If no error messages are from named, you can proceed to test the name server.
Remember: Before you try the caching name server, you have to specify that name server as your primary one. To do so, make sure this is the first line in the /etc/resolv.conf file:
nameserver 127.0.0.1
Now you can use host to test the name server. For example, to look up the IP address of www.gao.gov by using the caching name server on localhost, type the following command:
host www.gao.gov localhost
Here's the resulting output from the host command:
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:
www.gao.gov. has address 161.203.16.2
As the output shows, the host command uses localhost as the DNS server and returns the IP address of www.gao.gov. If you get an output similar to this, the caching name server is up and running.
Configuring a Primary Name Server
The best way to configure a primary name server is to start by configuring a caching name server (as explained in the previous sections). Then, add master zones for the domains for which you want this name server to be the primary name server. For example, suppose you want to define a primary name server for the server7.net domain. Here are the steps I go through to configure that primary name server on a Fedora system (after logging in as root):
- Add the following zone statements to the /etc/named.conf file:
zone "server7.net" IN {
type master;
file "server7.zone";
};
zone "0.168.192.in-addr.arpa" IN {
type master;
file "0.168.192.zone";
};
- Create the zone file /var/named/server7.zone with the following lines in it:
$TTL 86400
$ORIGIN server7.net.
@ 1D IN SOA @ root.server7.net (
100 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
1D IN NS @
1D IN A 192.168.0.7
wxp IN A 192.168.0.2
- Create the zone file /var/named/0.168.192.zone with the following lines in it:
$TTL 86400
; Remember zone name is: 0.168.192.in-addr.arpa
@ IN SOA server7.net. root.server7.net (
1 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS server7.net.
7 IN PTR server7.net.
2 IN PTR wxp.server7.net.
- To test the new configuration, restart the named server with the following command:
/etc/init.d/named restart
- Use dig or host to query the DNS server. For example, here's how to use host to check the address of the host wxp.server7.net at the DNS server running on localhost:
host wxp.server7.net localhost
This command results in the following output:
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:
wxp.server7.net has address 192.168.0.2
If you want to use dig to check the DNS server, type the following command:
dig @localhost wxp.server7.net
That @localhost part specifies the DNS server that dig contacts.
When you successfully use dig to contact a DNS server, you can get a bit fancier with what you ask that server to do. Here, for example, is the command to try a reverse lookup with the IP address 192.168.0.2:
host 192.168.0.2 localhost
This command displays the following output:
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:
2.0.168.192.in-addr.arpa domain name pointer wxp.server7.net