The Host File

Each entry in the /etc/hosts file contains an IP address and the names associated with that address.For example, the host table on our box might contain the following entries:

$ cat /etc/hosts
127.0.0.1 localhost localhost.localdomain
10.0.0.100 services services.linuxexposed.com
10.0.0.101 fun fun.linuxexposed.com


The first entry in this table assigns the name localhost to the address 127.0.0.1. (Every computer running TCP/IP assigns the loopback address to the hostname localhost.) Network 127 is a special network address reserved for the loopback network, and host 127.0.0.1 is the loopback address reserved for the local host. The loopback address is a special convention that permits the local computer to address itself in exactly the same way that it addresses remote computers. This simplifies software because the same code can be used to address any system, and because the address is assigned to a software loopback interface (lo), no traffic is sent to the physical network.

The second entry in the table is the entry for crow itself. The entry maps the address 10.0.0.100 to the name services.linuxexposed.com and to the alias services. Alias hostnames are primarily used to provide for shorter names, as in the example, but they are also used to provide generic names such as mailhost, news, and www. Every networked computer with a permanent address has its own hostname and address in its host table. Every Linux system has a host table with the two entries just discussed, and some, such as our host file, have a few additional entries for other key systems on the local network. This small table provides a backup for those times when DNS might not be running, such as during the boot process.

Understanding DNS

The limitations of the host table become obvious when it is used for a large number of hosts. The host table requires every computer to have a local copy of the table, and each copy must be complete because only computers listed in the local host table can be accessed by name. Consider today's Internet: It has millions of hosts. A host table with millions of entries is very inefficient to search and, more important, is impossible to maintain. Hosts are added to and deleted from the Internet every second. No system could maintain such a large and changeable table and distribute it to every computer on the network.

DNS solves these problems by eliminating the need for an all-inclusive, centrally maintained table by replacing it with a distributed, hierarchical database system. The current DNS database has millions of host entries, distributed among tens of thousands of servers. Distributing the database in this way reduces the size of the database handled by any individual server, which in turn reduces the task of maintaining any individual piece of the database. Additionally, DNS uses local caching to migrate information close to those who need it, without sending unnecessary information. A caching server starts with just the information it needs to locate the root of the hierarchical database. It then saves all of the answers to user queries that it receives and all of the supporting information learned in gaining those answers. In this way, it builds up an internal database of the information it needs to serve its users.

The DNS Hierarchy

The DNS hierarchy can be compared to the hierarchy of the Linux filesystem. Hostnames in individual domains parallel filenames in individual directories, and, like the root directory of the filesystem, DNS has a root domain.

In both the filesystem and the DNS system, the names of objects reveal the rooted hierarchical structure. Filenames move from the most general, the root (/), to the most specific, the individual file. Domain names start with the most specific, the host, and move to the most general, the root (.).A domain name that starts with a host and goes all the way to the root is called a fully qualified domain name (FQDN).

For example, services.linuxexposed.com is the FQDN of one of the systems on our
imaginary network.The top-level domains (TLDs)—such as org, edu, jp, and com—are serviced by the root servers. The second-level domain, services in the example, is the domain that has been officially assigned to our imaginary organization. When you're officially assigned a domain by your parent domain, a pointer is placed in the parent domain that points to your server as the server responsible for your domain. It is this delegation of authority that makes your domain part of the overall domain system.

The analogy to the filesystem goes beyond just the structure of names. Files are found by following a path from the root directory through subordinate directories to the target directory. DNS information is located in a similar manner. Linux learns the location of the root filesystem during the boot process from the grub.conf file or the lilo.conf file. Similarly, your DNS server locates the root servers during startup by reading a file, called the hints file, which contains the names and addresses of the root servers. Via queries, the server can find any host in the domain system by starting at the root and following pointers through the domains until it reaches the target domain.

Answering Queries

To answer a query for DNS information, the local name server must either have the answer to the query or know which name server does. No single system can have complete knowledge of all of the names in the Internet; servers know about their local domains and build up knowledge about other domains one query at a time.

Here's how it works. Assume you want the address of http://www.linuxexposed.com/. In effect, you are asking for the address record for www from the linuxexposed.com database. A query for that address record comes to the local name server. If the server knows the address of http://www.linuxexposed.com.com/, it answers the query directly. If it doesn't know the answer, but it knows which server handles linuxexposed.com, it queries that server. If it has no information at all, it queries a root server. The root server does not directly answer the address query. Instead, it points the local server to a server that can answer queries for the linuxexposed.com domain. It does this by sending the local server a name server record that tells it the name of the server for the linuxexposed.com domain and an address record that tells it the address of that server.

The local server then queries the linuxexposed.com domain server and receives the address for http://www.linuxexposed.com/. In this way, the local server learns the address of the host as well as the name and address of the servers for the domain. It caches these answers and will use them to directly answer queries about the linuxexposed.com domain without again bothering the root servers.

The BIND Software

On most Linux systems, DNS is implemented with the Berkeley Internet Name Domain (BIND) software. Two versions of BIND are currently in widespread use:

BIND 8 has been around for years, and is found in many releases of Linux.
BIND 9 is the most recent version of BIND and used for writing this article.,.

If you are running BIND 8, the information covered here is still applicable because BIND 8 and BIND 9 are very similar. Any differences are noted in the text.

BIND DNS is a client/server system. The client is called the resolver, and it forms the queries and sends them to the name server. Every computer on your network runs a resolver. Many systems only run a resolver.

Traditionally, the BIND resolver is not implemented as a distinct process. It is a library of software routines, called the resolver code, which is linked into any program that requires name service. Most Linux systems use the traditional resolver implementation, which is called a stub resolver. Because it is the most widely used, the stub resolver gets most of the coverage in this article. However, BIND 9 also offers the Lightweight Resolver library and the Lightweight Resolver daemon (lwresd) as an alternative to the traditional resolver.

The server side of BIND answers the queries that come from the resolver. The name server daemon is a distinct process called named. The configuration of named is much more complex than the configuration of the resolver, but there is no need to run named on every computer. Because all of the computers on your network—whether they are clients or servers—run the resolver, begin your DNS configuration by configuring the resolver.

Configuring the Resolver

The Linux resolver is configured by two types of files. One type tells the resolver which name services to use and in what order to use them. The other configuration file, /etc/resolv.conf, configures the resolver for its interaction with the Domain Name System. Every time a process that uses the resolver starts, it reads the resolv.conf
file, and caches the configuration for the life of the process. If the /etc/resolv.conf file is not found, a default configuration is used.

The default resolver configuration uses the hostname command to define the local domain. Everything after the first dot in the value returned by the hostname command is used as the default domain. For example, if hostname returns services.linuxexposed.com, the default value for the local domain is linuxexposed.com.

The default configuration uses the local system as the name server. This means that you must run named if you don't create a resolv.conf file. Generally, I think you should create a resolv.conf file, even if you do run named on the local host. There are three reasons for this. First, the resolv.conf file provides a means of documenting the configuration. Anyone can read the file and see the configuration you selected for the resolver. Second, the default values that work with one version of BIND may change with a future release. If you explicitly set the values you want, you don't have to worry about how the default values change. And third, even if you are using the local machine as a name server, the resolv.conf file allows you to define backup servers to increase robustness.

The Resolver Configuration Commands

The BIND 9 software uses the same resolver configuration file as the BIND 8 software used on many Linux systems. The commands it contains are identical to those found in a BIND 8 resolver configuration. resolv.conf is a text file that can contain the following commands:

nameserver address

The nameserver command defines the IP address of a name server the resolver should use. Up to three nameserver commands can be included in the configuration. The servers are queried in the order that they appear in the file until an answer is received or the resolver times out. (See the "Resolver Timeouts" sidebar for information about these timeouts.) Normally, the first name server answers the query. The only time the second server is queried is if the first server is down or unreachable. The third server is queried only if both the first and second servers are down or unreachable. If no nameserver entry is found in the resolv.conf file, the name server running on the local host is used as the default.

domain domainname

The domain command defines the local domain. The local domain is used to expand the hostname in a query before it is sent to the name server. If the domain command is not used, the values defined in the search command are used. If neither command is found in the resolv.conf file, the value derived from the hostname command is used. No matter how the local domain value is set, it can be overridden for an individual user by setting the environment variable LOCALDOMAIN.

search searchlist

The search command defines a list of domains that are used to expand a hostname before it is sent to the name server. searchlist contains up to six domain names, separated by whitespace. Each domain specified in the search list is searched in order until the query is answered. Unlike the domain command, which creates a default search list containing only the local domain, the search command creates an explicit search list containing every domain specified in searchlist.

options option

The options command modifies the standard behavior of the
resolver. There are several options available for BIND 8 and BIND 9:

debug
Turns on debugging. When the debug option is set, the resolver prints debugging messages to standard output. These messages are very informative for debugging resolver or server problems, but in reality, this option is of marginal value. Turning on debugging in the basic resolver configuration produces too much output, and produces it at inappropriate times. there allow you to turn on resolver debugging when you're ready to run the test so that you get the additional output at a time that you can actually use it.

ndots:n
Defines the number of dots that indicate when the resolver should append values from the search list to the hostname before sending the query to the name server. By default, the resolver will not modify a hostname if it contains one dot. As a result, the hostname
crow will be extended with a value from the search list before being sent to the name server, but the hostname sooty.terns will not. Use the ndots option to modify this behavior. For example: ndots:2. This option tells the resolver to use the search list on any hostname that contains less than two dots. With this setting, both crow and sooty.terns are extended with a value from the search list before being sent to the name server for the first time.

The ndots option changes how the resolver handles queries, but it only really changes the order in which things are done. The unmodified hostname is either the first or the last query sent to the name server. If ndots is set to 1 (the default setting), sooty.terns is
sent to the server without modification. When the server fails to resolve that name, the resolver issues additional queries with the search list values until it gets an answer or the list is exhausted. If ndots is set to 2, sooty.terns is modified with the first value in the
search list before it is sent to the name server. If the server fails to resolve the name, the resolver tries every value in the search list and then sends the unmodified hostname to the name server. In either case, exactly the same queries are made. Only the order of the queries is changed.

About the only time that ndots is required is if some component of your domain could be confused with a top-level domain, and you have users who consistently truncate hostnames at that domain. In that rare case, the queries would first be sent to the root servers for resolution in the top-level domain before eventually getting back to your local server. It is very bad form to bother the root servers over nothing. Use ndots to force the resolver to extend the troublesome hostnames with your local domain name so that they will be resolved before ever reaching the root servers.

timeout:n
Sets the initial query timeout for the resolver. By default, the timeout is five seconds for the first query to every server. Subsequent queries time out based on a formula that uses this initial value and the number of servers Change this value only if you know for certain that your name server generally takes longer than five seconds to respond. In that rare case, increasing this value reduces the number of duplicate queries.

attempts:n
Defines the number of times the resolver will retry a query. The default value is 2, which means the resolver will retry a query two times with every server in its server list before returning an error to the application. The attempt value might need to be increased if you have a poor network connection that frequently loses queries, such as the connection to a remote office in a developing country or at the end of a narrow-band satellite link. In most cases, this value does not need to be changed.

rotate
Turns on round-robin selection of name servers. Normally, the resolver sends the query to the first server in the name server list, and only sends the query to another server if the first server does not respond. Traditionally, the second and third name servers were
defined to provide backup name service. They were not intended to provide load-sharing. The rotate option configures the resolver to share the name server workload evenly among all of the servers.

no-check-names
Disables the checking of domain names for compliance with RFC 952, "DOD Internet Host Table Specification." By default, domain names that contain an underscore (_), non-ASCII characters, or ASCII control characters are considered to be in error.
Use this option to work with hostnames that contain an underscore. Philosophically, I'm not crazy about checking for bad names during the query process. Checking names at this point does not seem to be in the spirit of the old interoperability adage, "Be conservative in what you send and liberal in what you accept." Personally, I prefer to
control compliance with the RFCs at the source. The sources of incorrect domain names are the zone files that contain those names. I find it much better to use the name server features that check for incorrect names when the zone file is loaded than to check the names during a resolver query process. Therefore, I use this option to disable checking in the resolver.

inet6
Causes the resolver to query for IPv6 addresses. The version of the Internet Protocol (IP) used in today's Internet is IPv4. IPv4 uses the same 32-bit addresses used in this article . IPv6 uses different 128-bit addresses. IPv6 is a future protocol toward which networks are evolving. Use this option only if you connect to an experimental IPv6 network. This option would not be used in an average business environment.

sortlist addresslist
The sortlist command defines a list of network
addresses that are preferred over other addresses. The addresslist is a l i s t o f a d d r e s s a n d m a s k p a i r s ( f o r e x a m p l e ,10.0.0.100/255.255.255.0). To be of any use, it requires that the remote host have more than one address assigned to a single name, that the network path to one of those addresses be clearly superior to the others, and that you know exactly which path is superior. By default, address preference is set by the server, and addresses are used by the resolver in the order in which they are received.

A sortlist command that prefers the local subnet address above all others is the only sortlist that is commonly used. Many administrators use such a sortlist command as a matter of course. But trying to use the sortlist command to sort addresses from remote networks can do more harm than good unless you have a very clear understanding of exactly how the networks are configured and how they talk to each other. Therefore sortlist is rarely used to sort remote addresses.

The standard timeout for the first query is set to five seconds, and the resolver can use up to three name servers. The resolver sends the first query to the first server in the server list with a timeout of five seconds. If the first server fails to respond, the query is sent to the second server in the list with a timeout of five seconds. If the second server fails to respond, the query is sent to the third server in the list with a time-out of five seconds. Each server in the list is given a chance to respond, and each server is given the full five-second timeout. This first round of queries can take as long as 15 seconds.

If no server responds to the first round of queries, the previous timeout is doubled and divided by the number of servers to determine the new timeout value. The query is then sent again. By default, the resolver retries two times, although this can be changed with the retry command. Assuming the defaults, the resolver sends an initial query and two retries for a total of three attempts, which gives the following timeouts:


Timeouts with one server

The first query has a timeout of five seconds, the second of 10 seconds, and the third of 20 seconds. Given this, the resolver waits up to 35 seconds before abandoning the query when one server is defined.


Timeouts with two servers

The first round of queries has a timeout of five seconds for each server, the second round is also five seconds, and the third round is 10 seconds. This gives a total timeout value of 20 seconds for each server, which means the resolver waits up to 40 seconds before abandoning a query when two servers are defined.


Timeouts with three servers

The first round of queries has a timeout of five seconds for each server, the second round is three seconds, and the third round is six seconds. (Dividing 10 or 20 by 3 does not yield a whole number—the time-out values 3 and 6 are truncated, whole number values.) This gives a total timeout value of 14 seconds for each server, which means the resolver waits up to 42 seconds before abandoning a query when three servers are defined.

Without this formula, which reduces the timeout based on the number servers, two retries with three servers would take up to 105 seconds to time out if the resolver used the same 5-, 10-, and 20-second timeout values used for one server. Even the most patient user would become exasperated! Additionally, when multiple name servers are used, it is not necessary to give each of them as much time to resolve the query. It is highly unlikely that they will all be down at the same time. A query timeout when three servers are configured probably indicates that there is something wrong with your local network, not with all three remote servers. Because of this timeout formula, the added reliability of three servers only costs, at most, seven seconds.


A Sample resolv.conf File


Assume you're configuring a Linux workstation named mute.test.linuxexposed.com (10.0.0.3) that does not run its own name server.

$ cat /etc/resolv.conf
search test.linuxexposed.com linuxexposed.com
nameserver 10.0.0.100
nameserver 10.0.0.101


The search command tells the resolver to expand hostnames, first with the local subdomain test.linuxexposed.com and then with the parent of that domain linuxexposed.com . This explicit list gives the workstation's users the behavior they have come to expect. In earlier versions of BIND, the default was to search the local domain and its parents. The default in BIND 8 and BIND 9 is to search only the default domain. This explicit search list emulates the old behavior.

The domain command and the search command are mutually exclusive. Whichever command appears last in the resolv.conf file is the one that defines the search list. To have more than one domain in the search list, use the search command. The default value derived from the hostname command, the value entered by the domain command, and the value assigned to the LOCALDOMAIN environment variable defines just one domain—the local domain. The local domain then becomes the only value in the search list. The search command is the preferred method for defining the search list.

The Lightweight Resolver

BIND 9 introduces a new, lightweight resolver library. The new library can be linked into any application, but it was designed for applications that need to use IPv6 addresses. Support for IPv6 has increased the complexity of the resolver to the point that it is difficult to implement as a traditional stub resolver. For this reason, the lightweight resolver splits the resolver into a library used by the applications and a separate resolver daemon that handles the bulk of the resolver process. The library routines send queries to UDP port 921 on the local host using the lightweight resolver protocol. The resolver daemon takes the query, and resolves it using standard DNS protocols.

The resolver daemon is lwresd. It is essentially a caching-only name server that recursively resolves queries for the lightweight resolver library. lwresd does not require the same level of configuration as a caching-only server because some default values, such as the list of root servers, are compiled into lwresd. Instead, lwresd uses the same configuration commands as the stub resolver, and it reads its configuration from resolv.conf. However, lwresd interprets the nameserver commands in a slightly different manner.

If nameserver commands are defined in resolv.conf, lwresd treats the servers listed there as forwarders. It attempts to forward all queries to those servers for resolution. lwresd is started by the lwresd command. Red Hat does not include a boot script for lwresd. If you need to run lwresd to support IPv6 on your network, add a lwresd command to the rc.local startup script.

The lwresd command uses the following syntax:

lwresd [-C config-file] [-d debuglevel] [-f -g -s] [-i pid-file]
[-n #threads] [-P listen-port] [-p port] [-t directory]
[-u user-id] [-v]

The lwresd command has several arguments, most of which you will never use. They are as follows:

-C config-file Defines the pathname of the configuration file if /etc/resolv.conf is not used. It is always best to use the standard configuration file to simplify troubleshooting.
-d debuglevel Enables debug tracing. This is the same debugging output used with named.
-f Runs lwresd in the foreground instead of running it in the background as a standard daemon. Generally, this is used only for debugging.
-g Runs lwresd in the foreground, and logs everything through stderr. Again, this is used only for debugging.
-s Writes memory usage statistics to stdout. This is of interest only to the BIND developers.
-i pid-file Defines the pathname of the file in which lwresd writes its process ID. The default is /var/run/lwresd.pid. Changing default pathnames gains nothing and complicates troubleshooting.
-n #threads Specifies the number of threads that should be created by lwresd. By default, lwresd creates one thread for each CPU.
-P listen-port Specifies the port that should be used for queries from the lightweight resolver library. The standard port is 921. Changing the port complicates troubleshooting.
-p port Specifies the port on which DNS queries should be sent to the name servers. The standard port is port 53. This is changed only for special testing with a server that uses a non-standard port.
-t directory Defines a chroot directory to run lwresd chroot. If -t is used, lwresd will chroot to directory after reading /etc/resolv. This is used to limit the access that lwresd has to the filesystem in case the lwresd process is compromised by an intruder.
-u user-id Defines the user ID under which the lwresd process will run. Lwresd starts under the root user ID, and changes to user-id after completing privileged operations, such as binding to port 921. This is used to limit the damage an intruder could do if he gains control of the lwresd process.
-v Reports the version number, and exits.

In most cases, the lwresd command is run without any options. The defaults are correct for most lwresd configurations. And remember, lwresd is not needed for most systems. Most applications use the traditional stub resolver.

Configuring a Domain Name Server

There are three basic name server configurations:

A caching server is a non-authoritative server. It gets all of its answers to name-server queries from other name servers.
•
The slave server is considered an authoritative server because it has a complete and accurate domain database that it transfers from the master server. It is also called the secondary server because it is the backup for the primary server.
•
The master server is the primary server for the domain. It loads the domain information directly from a local disk file maintained by the domain administrator. The master server is

considered authoritative for the domain, and its answers to queries are always considered to be accurate.
•
Most servers combine elements of more than one configuration. All servers cache answers, and many primary servers are secondary for some other domain. Mix and match these server configurations on your server as needed for your network.

Create only one master server for your domain. It is the ultimate source of information about your domain. Creating more than one master could undermine the reliability of the data. Create at least one slave server. It shares the workload, and provides backup for the master server. Most domain administrators create two official slave servers to increase reliability. Use caching servers throughout the network to reduce the load on the master and secondary servers, and to reduce network traffic by placing name servers close to your users. To enhance performance, many network administrators place a caching server on each subnet or in each department.

Up to five different types of files are required for a named configuration. All configurations require these three basic files:

named configuration file

The named.conf configuration file defines basic parameters, and points to the sources of domain database information, which can be local files or remote servers.

hints file

The hints, or cache, file provides the names and addresses of the root servers that are used during startup.

local host file

All configurations have a local domain database for resolving the loopback address to the hostname localhost.

zone file

The zone file defines most of the information. It is used to map hostnames to addresses, to identify the mail servers, and to provide a variety of other domain information.

reverse zone file

The reverse zone file maps IP addresses to hostnames, which is exactly the opposite of what the zone file does.

A zone is the piece of the domain namespace over which a master server has authority. The domain database file that contains the information about the zone is called a zone file. A zone and a domain are not equivalent. For example, everything in the database file is in a single zone, even if the file contains information about more than one domain.
To configure DNS, you need to understand how to configure all five configuration files.

Let's start by looking at the named.conf file. It is used on every name server, and defines the basic configuration.

The named Configuration File

When BIND 8 was introduced, everything about the named configuration file changed: its name, the commands it contains, the structure of the commands, and the structure of the file. Administrators familiar with configuring the previous version of BIND were forced to start from scratch. But the introduction of BIND 9 has been less traumatic. The BIND 9 named.conf file has the same structure, a similar syntax, and only two additional commands.

The structure of the named.conf configuration commands is similar to the structure of the C programming language. A statement ends with a semicolon (;), literals are enclosed in quotes (""), and related items are grouped together inside curly braces ({}). BIND provides three ways to insert a comment. A comment can be enclosed between /* and */, like a C language comment. It can begin with two slashes (//), like a C++ comment; or it can begin with a hash mark (#), like a shell comment. The examples in this article use C++ style comments, but you can use any of the three valid styles that you like.


The options Statement

Most named.conf files open with an options statement. Only one options statement can be used. The options statement defines global parameters that affect the way BIND operates. It also sets the defaults used by other statements in the configuration file. The most commonly used options statement defines the working directory for the server:

options {
directory "/var/named"
};

The statement starts with the options command. The curly braces enclose a list of options, and the keyword directory defines the directory that named will read files from and write files to. The directory name is also used to complete any filename specified in the configuration file. The literal enclosed in quotes is the pathname of the directory. Notice that both the directory clause and the options statement end with a semicolon.

As you'll see in the section on the named control tool later in this article, named writes several different files that are used to check the status of the name server. The options statement can be used to change the default pathnames of the individual files. However, it is generally best to keep the standard name for each status file and to store these files in the directory identified by the directory command. Doing so makes things simpler for others who attempt to diagnose a name server problem on your system.

Several options can be set that affect all zones or all servers. In most cases, it is better to set those values specifically for the zone or server that is being affected. The designers of BIND have set the defaults correctly for the vast majority of zones and servers. Zones and servers that need other values are exceptions, and they should be treated as such by defining the exceptional characteristics directly on the zone or server statement—not in the options statement.

One option used on occasion is forwarders. The forwarders option causes the local server to forward to a specific list of servers all queries that it cannot resolve from its own cache. This builds a rich cache on the selected servers. The selected servers should be on your local network because the point of building the rich cache is to reduce the number of queries sent over the wide area network. This is primarily useful if your WAN charges for usage, as some ISDN networks do.

A sample forwarders option is

options {
directory "/var/name";
forward first;
forwarders { 10.0.0.100; 10.0.0.101; };
};


The forward first option says that the local server should try the forwarders before it tries to get an answer from any other external server. This is the default, so this option really didn't need to be specified. The other possible value is forward only, which tells the server that it can talk only to the forwarders. Even if the forwarders are not responding, the local server is not allowed to find the answer itself when forwarders only is specified. The forwarders option lists the addresses of the servers to which queries are forwarded.

The zone Statement

The zone statements are the most important statements in the configuration file, and they constitute the bulk of the named.conf file. A zone statement performs the following critical configuration functions:

It defines a zone that is serviced by this name server.
It defines the type of name server that this server is for the zone. A server can be a master
server or a slave server. And because this is defined on a per-zone basis, the same server
can be the master for some zones while being a slave for others.
It defines the source of domain information for a zone. The domain database can be loaded
from a local disk file or transferred from the master server.
It defines special processing options for the zone. •

A sample zone statement illustrates all of these functions:

zone "linuxexposed.com" in {
type master;
file "linuxexposed.hosts";
check-names fail;
notify yes;
also-notify { 10.0.0.103; };
allow-update { none; };
};


The statement begins with the zone command. The name of the zone is written as a literal enclosed in quotes. The in keyword means that this zone contains IP addresses and Internet domain names. This is the default, so in is not really required. The curly braces enclose a list of options for this zone.

A Caching-Only Configuration

The caching-only configuration is the foundation of all server configurations because all servers cache answers. This name.conf file is based on the sample found in the BIND 9 documentation with slight modifications for our imaginary network.

$ cat /etc/named.conf
//
// accept queries from the local subnet
//
acl "subnet12" { 10.0.0.0/24; };
options {
directory "/var/named";
allow-query { "subnet12"; };
};
//
// a caching only nameserver config
//
zone "." {
type hint;
file "named.ca";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};


The named.conf file opens with an access control list. Use the acl command to assign an arbitrary name to a list of items that will be subsequently referenced by that name the acl command assigns the name subnet12 to a list of addresses. In this case, the list contains only one network address, but it could have contained more. The name subnet12 is then referenced in the allow-query option in the options statement.

The allow-query option limits the clients from which DNS queries will be accepted. By default, a BIND server accepts queries from any source. However, a caching-only server is not advertised to the outside world, and in general is intended to service only a limited number of local systems. The allow-query option ensures that this server will only provide service to the clients on network 10.0.0.0.

The two zone statements in this caching-only configuration are found in all server configurations. The first zone statement defines the hints file that is used to help the name server locate the root servers during startup. The second zone statement makes the server the master for its own loopback address, and points to the local host file.

The Hints File

The hints file contains information that named uses to initialize the cache. As indicated by the root domain (".") name on the zone statement, the hints the file contains are the names and addresses of the root name servers. The file helps the local server locate a root server during startup. After a root server is located, an authoritative list of root servers is downloaded from that server. The hints are not referred to again until the local server restarts.

The named.conf file points to the location of the hints file. The hints file can be given any filename. Commonly used names are named.ca, named.root, and root.cache.

. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33

The hints file contains only name server (NS) and address (A) records. Each NS record identifies a name server for the root domain (.). The associated A record gives the IP address for each server. The structure of these database entries will become clear later in the article. For now, it is important to realize that you do not directly create or edit this file.

The Local Host File


Every name server is the master of its own loopback domain, which of course makes sense. The whole point of creating the loopback interface (lo) is to reduce network traffic. Sending domain queries about the loopback address across the network would defeat that purpose.

The loopback domain is a reverse domain. It is used to map the loopback address 127.0.0.1 to the hostname localhost. On our sample Red Hat system, the zone file for this domain is called named.local, which is the most common name for the local host file.

The Slave Server Configuration

Configuring a slave server is almost as simple as configuring a caching-only server. It uses the same three configuration files with only minor modifications to the named.conf file. Because of this, you can start with a caching-only configuration to test your system before you configure it as a slave server. Our sample slave server will be built by modifying the common caching-only

$ cat /etc/named.conf
options {
directory "/var/named";
};
// a slave server configuration
//
zone "." {
type hint;
file "named.ca";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};
zone "linuxexposed.com" {
type slave;
file "linuxexposed.hosts";
masters { 10.0.0.103; };
allow-updates { none; };
};
zone "0.10.in-addr.arpa" {
type slave;
file "10.0.reverse";
masters { 10.0.0.1; };
allow-updates { none; };
};


The configuration file contains all of the zone statements that have already been discussed because all servers use a hints file and a loopback domain database file. The two new zone statements declare zones for the domains foobirds.org and 0.16.172.in-addr.arpa. The type clause in each of the new zone statements says that this is a slave server for the specified domains.

The masters clause identifies the master server. There can be more than one IP address provided in this clause, particularly if the master server is multihomed and thus has more than one IP address. In most configurations, only one address is used, which is the address of the master server for the specified zone.

The slave server downloads the entire zone file from the master server. This process is called a zone file transfer. When the file is downloaded, it is stored in the file identified by the file clause. Don't create or edit this file; it is created automatically by named. After the zone is downloaded, it loads directly from the local disk. The slave will not transfer the zone again until the master server updates the zone.

The Master Server Configuration

The named.conf file for a master server looks very much like the configuration file for a secondary server.

$ cat /etc/named.conf
options {
directory "/var/named";
};
// a master nameserver config
//
zone "." {
type hint;
file "named.ca";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};
zone "foobirds.org" {
type master;
file "linuxexposed.hosts";
notify yes;
allow-updates { none; };
};
zone "0.10.in-addr.arpa" {
type master;
file "10.0.reverse";
notify yes;
allow-updates { none; };
};

So far, the configuration of the master server is the same as any other server—you create a configuration file, a hints file, and a local host reverse zone file. The difference comes from the fact that you must also create the real domain database files.

DNS Database Records

The database records used in a zone file are called standard resource records or sometimes just RRs. All resource records have the same basic format:

[name] [ttl] IN type data


The name field identifies the domain object affected by this record. It could be an individual host or an entire domain. Unless the name is a fully qualified domain name, it is relative to the current domain.

A few special values can be used in the name field. These are A blank name refers to the last named object. The last value of the name field stays in force until a new value is specified.

@ An at-sign refers to the current origin. The origin is the default domain name used inside the zone file. You can set the origin in the database file with the $ORIGIN directive. If a $ORIGIN directive is not used, the origin is the domain name from the zone command in the named.conf file. * An asterisk is a wildcard character that can be used to match any character string.

The time-to-live (ttl) field defines the length of time that this resource record should be cached. This permits you to decide how long remote servers should store information from your domain. You can use a short TTL for volatile information and a long TTL for stable information. If no TTL value is specified, the default TTL value defined by the $TTL directive is used.

The class field is always IN, which is shown in the syntax above. There really are three possible values: HS for Hesiod servers, CH for Chaosnet servers, and IN for Internet servers. All of the information you deal with is for TCP/IP networks and Internet servers, so you will not use the other values.

The type field defines the type of resource record. There are 40 different types of records; almost all of which are experimental, obsolete, or unused.

Record Name Record Type Function
Start of Authority SOA Marks the beginning of a zone's data, and defines
parameters that affect the entire zone
Name Server NS Identifies a domain's name server
Address A Maps a hostname to an address
Pointer PTR Maps an address to a hostname
Mail Exchanger MX Identifies the mail server for a domain
Canonical Name CNAME Defines an alias for a hostname


Zone File Directives

The four directives are evenly divided into two that simplify the construction of a zone file, $INCLUDE and $GENERATE; and two that define values used by the resource records, $ORIGIN and $TTL.

The $TTL Directive Defines the default TTL for resource records that do not specify an explicit time to live. The TTL value can be specified as a number of seconds, or as a combination of numbers and letters. Defining one week as the default TTL using seconds is

$TTL 604800

Using the alphanumeric format, one week can be defined as

$TTL 1w


The letter values that can be used with the alphanumeric format are

w for week 
d for day 
h for hour 
m for minute 
s for second 


The $ORIGIN Directive Sets the current origin, which is the domain name used to complete any relative domain names. By default, $ORIGIN starts out assigned the domain name defined on the zone statement. Use the $ORIGIN directive to change the setting.

Like all names in a zone file, the domain name on the $ORIGIN directive is relative to the current origin, unless it is fully qualified. Thus, if the zone statement defines the domain foobirds.org and the zone file contains the following $ORIGIN directive:

The $INCLUDE Directive Reads in an external file, and includes it as part of the zone file. The external file is included in the zone file at the point where the $INCLUDE directive occurs. The $INCLUDE directive makes it possible to divide a large domain into several different files. This might be done so that several different administrators can work on various parts of a zone without having all of them try to work on one file at the same time. The directive begins with the $INCLUDE keyword, which is followed by the name of the file to be included. All filenames in the zone file are relative to the directory pointed to by the directory option in the named.conf file, unless fully qualified to the root.

The $GENERATE Directive The $GENERATE directive create a series of resource records. The resource records generated by the $GENERATE directive are almost identical, varying only by a numeric iterator. An example shows the structure of the $GENERATE directive:

$ORIGIN 20.16.172.in-addr.arpa.
$GENERATE 1-4 $ CNAME $.1to4

The $GENERATE keyword is followed by the range of records to be created. In the example, the range is 1 through 4. The range is followed by the template of the resource records to be generated. In this case, the template is $ CNAME $.1to4. A $ sign in the template is replaced by the current iterator value. In the example, the value iterates from 1 to 4. This $GENERATE directive produces the following resource records:

1 CNAME 1.1to4
2 CNAME 2.1to4
3 CNAME 3.1to4
4 CNAME 4.1to4

Given that 20.16.172.in-addr.arpa. is the value defined for the current origin, these resource records are the same as

1.20.16.172.in-addr.arpa. CNAME 1.1to4.20.16.172.in-addr.arpa.
2.20.16.172.in-addr.arpa. CNAME 2.1to4.20.16.172.in-addr.arpa.
3.20.16.172.in-addr.arpa. CNAME 3.1to4.20.16.172.in-addr.arpa.
4.20.16.172.in-addr.arpa. CNAME 4.1to4.20.16.172.in-addr.arpa.

Now that you know what records and directives are available and what they look like, you're ready to put them together to create a database.

The Domain Database File


The domain database file contains most of the domain information. Its primary function is to convert hostnames to IP addresses so A records predominate, but this file contains all of the database records except PTR records. Creating the domain database file is both the most challenging and the most rewarding part of building a name server.

A Sample DNS Zone file

;
; The foobirds.org domain database
;
$TTL 1w
@ IN SOA wren.foobirds.org. sara.wren.foobirds.org. (
2002030601 ; Serial
21600 ; Refresh
1800 ; Retry
604800 ; Expire
900 ) ; Negative cache TTL
; Define the nameservers
IN NS wren.foobirds.org.
IN NS falcon.foobirds.org.
IN NS bear.mammals.org.
; Define the mail servers
IN MX 10 wren.foobirds.org.
IN MX 20 parrot.foobirds.org.
;
; Define localhost
;
localhost IN A 127.0.0.1
;
; Define the hosts in this zone
;
wren IN A 172.16.5.1
parrot IN A 172.16.5.3
crow IN A 172.16.5.5
hawk IN A 172.16.5.4
falcon IN A 172.16.5.20
puffin IN A 172.16.5.17
IN MX 5 wren.foobirds.org.
robin IN A 172.16.5.2
IN MX 5 wren.foobirds.org.
redbreast IN CNAME robin.foobirds.org.
www IN CNAME wren.foobirds.org.
news IN CNAME parrot.foobirds.org.
;
; Delegating subdomains
;
swans IN NS trumpeter.swans.foobirds.org.
IN NS parrot.foobirds.org.
terns IN NS arctic.terns.foobirds.org.
IN NS trumpeter.swans.foobirds.org.
;
; Glue records for subdomain servers
;
trumpeter.swans IN A 172.16.12.1
arctic.terns IN A 172.16.6.1

The SOA record All zone files begin with an SOA record. The @ in the name field of the SOA record refers to the current origin, which in this case is foobirds.org because that is the value defined in the zone statement of the configuration file. Because it ties the domain name back to the named configuration file, the name field of the SOA record is usually an at-sign.

The data field of the SOA record contains seven different components. It is so long, the data field of the SOA record normally spans several lines. The parentheses are continuation characters. After an opening parenthesis, all data on subsequent lines are considered part of the current record until a closing parenthesis. The components of the data field in the sample SOA record contain the following values:

wren.foobirds.org This is the hostname of the master server for this zone.

sara.wren.foobirds.org This is the e-mail address of the person responsible for this domain. Notice that the at-sign (@) normally used between the username (sara) and the hostname (wren.foobirds.org) in an e-mail address is replaced here with a dot (.).

2002030601 This is the serial number, a numeric value that tells the slave server that the zone file has been updated. To make this determination, the slave server periodically queries the master server for the SOA record. If the serial number in the master server's SOA record is greater than the serial number of the slave server's copy of the zone, the slave transfers the entire zone from the master. Otherwise, the slave assumes it has a current copy of the zone, and skips the zone transfer. The serial number should be increased every time the domain is updated in order to keep the slave servers synchronized with the master.

21600 This is the length of time in the refresh cycle. Every refresh cycle, the slave server checks the serial number of the SOA record from the master server to determine whether the zone needs to be transferred. The length of the refresh cycle can be defined using either a numeric or an alphanumeric format. (See the discussion of the $TTL directive for the details of these formats.) it uses the numeric format to set the refresh cycle to 21,600 seconds, which tells the slave server to check four times per day. This indicates a stable database that does not change very frequently, which is often the case. Computers are added to the network periodically, but not usually on an hourly basis. When a new computer arrives, the hostname and address are assigned before the system is added to the network because the name and address are required to install and configure the system. Thus, the domain information is disseminated to the slave servers before users begin to query for the address of the new system. A low refresh cycle keeps the servers tightly synchronized, but a very low value is not usually required because the DNS NOTIFY message sent from the master server causes the slave to immediately check the serial number of the SOA record when an update occurs. The refresh cycle is a redundant backup for DNS NOTIFY.

1800 This is the retry cycle. The retry cycle defines the length of time that the slave server should wait before asking again when the master server fails to respond to a request for the SOA record. The length of time can be specified using either a numeric or an alphanumeric format. In this example, the numeric format is used to specify a retry time of 1800 seconds (30 minutes). Don't set the value too low—a half-hour or 15 minutes are good retry values. If the server doesn't respond, it may be down. Quickly retrying a down server gains nothing, and wastes network resources.

604800 This is the expiration time, which is the length of time that the slave server should continue to respond to queries, even if it cannot update the zone file. The idea is that at some point in time, out-of-date data are worse than no data. This should be a substantial amount of time. After all, the main purpose of a slave server is to provide backup for the master server. If the master server is down and the slave stops answering queries, the entire network is down instead of having just one serve down. A disaster, such as a fire in the central computer facility, can take the master server down for a very long time. The time can be specified in either numeric or alphanumeric format.

900 This is the default time-to-live that servers should use when caching negative information about this zone. All servers cache answers, and use those answers to respond to subsequent queries. Most of the answers cached by a server are

standard resource records, which is positive information from the DNS database. A name server can also learn from the authoritative server for a zone that a specific piece of information does not exist, which is negative information. For example, the response to a query for bittern.foobirds.org would be that the domain name does not exist. This is valuable information that also should be cached. But with no associated resource record, and thus no explicit TTL, how long should it be cached? The negative cache TTL from the zone's SOA record tells remote servers how long to cache negative information. The SOA record it sets the negative cache value to 15 minutes (900 seconds). The negative cache TTL can be defined in either numeric or alphanumeric format. Use a negative cache of no more than 15 minutes—five minutes isn't bad either.

All of the components of the data field of the SOA record set values that affect the entire domain. Several of these items affect remote servers. You decide how often slave servers check for updates, and how long caching servers keep your data in their caches. The domain administrator is responsible for the design of the entire domain.

Defining the Name Servers

the NS records that follow the SOA record define the official name servers for the domain. Unless the also-notify option is used in the zone statement of the named.conf file, these are the only servers that receive a DNS NOTIFY message when the zone is updated.

Although they can appear anywhere in the file, the NS records often follow directly after the SOA record. When they do, the name field of each NS record can be blank. Because the name field is blank, the value of the last object named is used. the last value to appear in the name field was the @ that referred to the foobirds.org domain defined in the named.conf file. Therefore, these NS records all define name servers for the foobirds.org domain.

The first two NS records point to the master server wren and the slave server falcon that we configured earlier. The third server is external to our network. Name servers should have good network connections, and slave name servers should have a path to the Internet that is independent from the path used by the master server. This enables the slave server to fulfill its purpose as a backup server, even when the network that the master server is connected to is down. Large organizations may have independent connections for both servers; small organizations usually do not. If possible, find a server that is external to your network to act as a slave server. Check with your Internet Service Provider (ISP); it may offer this as a service to its customers.

Defining the Mail Servers

The first two MX records define the mail servers for this domain. The name field is still blank, meaning that these records pertain to the last named object, which in this case is the entire domain. The first MX record says that wren is the mail server for the
foobirds.org domain, with a preference of 10. If mail is addressed to user@foobirds.org, the mail is directed to wren for delivery.

The second MX record identifies parrot as a mail server for foobirds.org with a preference of 20. The lower the preference number, the more preferred the server. This means that mail addressed to the foobirds.org domain is first sent to wren. Only if wren is unavailable is the mail sent to parrot. parrot acts as a backup for those times when wren is down or offline.

These two MX records redirect mail addressed to the domain foobirds.org, but they do not redirect mail addressed to an individual host. Therefore, if mail is addressed to jay@hawk.foobirds.org, it is delivered directly to hawk; it is not sent to a mail server. This configuration permits people to use e-mail addresses of the form user@domain when they like, or to use direct delivery to an individual host when they want that. It is a very flexible configuration.

Defining the Host Information

The bulk of the zone file consists of address records that map
hostnames to IP addresses. The first address record in the domain database file in the maps the name localhost.foobirds.org to the loopback address 127.0.0.1. The reason this entry is included in the database has something to do with the way that the resolver constructs queries. Remember that if a hostname contains no dots, the resolver extends it with the local domain. So when a user enters telnet localhost, the resolver sends the name server a query for localhost.foobirds.org. Without this entry in the database, the resolver would make multiple queries before finally finding localhost in the /etc/hosts file. The localhost entry is followed by several address entries for individual hosts in the domain.

The only other unexplained records in the our DNS zone that defines host information are the CNAME records. The first CNAME record says that redbreast is a hostname alias for robin. Aliases are used to map an obsolete name to a current name or to provide generic names such as www and news. Aliases cannot be used in other resource records. Therefore, take care when placing CNAME records in the domain database. You have seen several examples of the fact that a blank name field refers to the previously named object. If the CNAME record is placed improperly, a record with a blank name field can illegally reference a nickname.

Running named
named is started at boot time by one of the startup scripts. On a Red Hat system, it is started by the /etc/rc.d/init.d/named script. The script checks that the named program and the named.conf file are available, and it then starts named. After the configuration files are created, named will restart whenever the system reboots.

Of course, it is not necessary to reboot in order to run named. You can run the named boot script from the command line. The Red Hat script accepts several arguments:

start Starts named if it is not already running.
stop Terminates the currently running named process.
restart Unconditionally terminates the running named process, and starts a new named process.
condrestart Does the same thing as restart, but only if named is currently running. If named is not running, no action is taken.
reload Uses the named management tool (rndc) to reload the DNS database files into the server. If rndc fails to reload the files, the script attempts to force a reload by sending a signal to named.
probe Uses the named management tool (rndc) to reload the DNS database files into the server. If rndc fails to reload the files, the script attempts to start named.
status Displays information about whether or not named is running.

Running boot scripts from the command line is so useful and popular that Red Hat provides a script named /sbin/service for the sole purpose of running boot scripts. The syntax of the service command is simple:

service script command

If your Linux system does not have a named script such as the one provided by Red Hat, you can start named from the command line by typing named &. However, named is rarely started from the command line because it automatically starts at every boot, and because rndc and signal processing mean that it does not need to be stopped and started to load a new configuration. Before discussing rndc, let's look at how signals can be used to cause named to load a new configuration and to perform a number of other tasks.

Last Words

Name service is a fundamental service of a Linux network. A name service converts text-based hostnames to the numeric IP address required by the network. In the same way that the services in

DNS is implemented on most Linux systems with the Berkeley Internet Name Domain (BIND) software, which is the most widely used DNS software in the Internet. Linux is a fairly new operating system, but it benefits from the fact that it can run venerable software packages such as BIND that have a very long history with many years of debugging and refinement. Linux developers wisely used these tried-and-true packages for the most critical network servers.

Be first to comment this article

Write Comment
Please keep the topic of messages relevant to the subject of the article. Personal verbal attacks will be deleted. Please don't use comments to plug your web site. Such material will be removed. Just ensure to *Refresh* your browser for a new security code to be displayed prior to clicking on the 'Send' button. Keep in mind that the above process only applies if you simply entered the wrong security code.
Name:
Comment:
Code:*