Setting Up a Domain Name System Server

Setting Up a Domain Name System Server

The Domain Name System (DNS) is essentially a distributed database that translates host names into IP addresses (and IP addresses back to host names). That database also contains information related to each domain, such as how the domain is organized into zones, where to route mail for that domain, and who to contact with questions associated with the domain.

By setting up a DNS server, you become part of a hierarchy of DNS servers that make up the Internet. At the top of this hierarchy is the root server, represented by a dot ("."). Below the root server are the Top Level Domains, or TLDs (such as .com, .org, and so on). Domains that individual organizations own and maintain lie below the TLDs. That's where you come in.

As someone who's setting up a DNS server, you're responsible for managing the host names and IP addresses for the computers in the domain (or domains) for which you're responsible. Keeping your DNS information correct means that people can access the services that you want to share, and the Internet as a whole works that much better as a result.

Besides using your DNS server to help people from the Internet find the public servers in your domain, you can also use DNS to provide name and IP address mapping for computers on your private network. The example in the "DNS name server example" section later in this chapter describes how to configure both private and public name and IP address records for a domain.


Setting up a DNS server can be a complex and (these days) potentially dangerous undertaking. A compromised DNS server can cause requests for host addresses to be directed to a cracker's server. The sample DNS server in this section is one created as an example of a DNS server for a home or small office environment. For information on the many different ways to set up a DNS server, open the BIND 9 Administrator Reference manual in a Web browser: /usr/share/doc/bind-9.2.2/arm/Bv9ARM.html.

Understanding DNS

The basic function of a name server is to answer queries by providing the information that those queries request. A DNS name server primarily translates domain and host names into IP addresses. Each domain is typically represented by at least two DNS servers.

  • Primary (master) name server:???This name server contains authoritative information about the domains that it serves. In response to queries for information about its domains, this server provides that information marked as being authoritative. The primary is the ultimate source for data about the domain. The secondary name server only carries the same authority in that it has received and loaded a complete set of domain information from the primary.

  • Secondary (slave) name server:???This name server gets all information for the domain from the primary. As is the case for the primary, DNS considers the secondary's information about the domain that it serves authoritative. (You set secondary servers in the NS RR records for the zone in the named.conf file on the primary.)

NS records in the parent zone for a domain list the primary and one or more secondary name servers. This delegation of servers defines the servers that have authority for the zone.

Because zone records change as you add, remove, or reconfigure the computers in the zone, you assign expiration times for information about your zone. You set the expiration time in the time to live (TTL) field, in the named.conf file (which I describe later).

Other specialized types of DNS servers are possible as well. Although these types of servers don't have authority for any zones, they can prove useful for special purposes:

  • Caching name server ( This type of server simply caches the information it receives about the locations of hosts and domains. It holds information that it obtains from other authoritative servers and reuses that information until the information expires (as set by the TTL fields).

  • Forwarding name server ( Creating a server that's not authoritative for a zone but that can forward name server requests to other name servers may prove efficient. This server is essentially a caching name server, but is useful in cases where computers lie behind a firewall and in which only one computer can make DNS queries outside that firewall on behalf of all the internal computers.

Understanding authoritative zones

As an administrator of a DNS server, you need to configure several zones. Each zone represents part of the DNS namespace as you view it from your DNS server. Besides the one or more zones representing your domain, you have a zone that identifies your local host and possibly your local, private LAN.

If you configure a server as authoritative for a zone, that server has the last word on resolving addresses for that zone. Your master name server is authoritative for the domain you configure in the "DNS name server example" section but not for domains outside your domain.

Remember that the DNS server that you configure is the ultimate authority for your zone. Other zones don't know how you configure your host names and IP addresses unless you properly set up your DNS server to distribute that information across the Internet.

The definitive data that you set up for your domain exists in the form of resource records. Resource records consist of the data associated with all names below the authoritative point in the tree structure. When the DNS server uses these records to reply to queries, it sets the authoritative answer (AA) bit in the packet that includes the reply. The AA bit indicates that your name server has the best and most current information available about your domain.

Understanding BIND

In Red Hat Linux (and most other Linux and UNIX systems), you implement DNS services by using the Berkeley Internet Name Domain (BIND) software. The Internet Software Consortium maintains BIND (at The particular version of BIND that I describe in this chapter is BIND 9.

The basic components of BIND include the following:

  • DNS server daemon (/usr/sbin/named):???The named daemon listens on a port (port number 53 by default) for DNS service requests and then fulfills those requests based on information in the configuration files that you create. Mostly, named receives requests to resolve the host names in your domain to IP addresses.


    The named daemon actually launches from the /etc/init.d/named startup script. You need to set that script to start automatically after your DNS server is ready to go. You can also use the named startup script to check the status of the named daemon.

  • DNS configuration files (named.conf and /var/named/*):???The /etc/named.conf file is where you add most of the general configuration information that you need to define the DNS services for your domain. Separate files in the /var/named directory contain specific zone information.

  • DNS lookup tools:???You can use several tools to check that your DNS server is resolving host names properly. These include commands such as host, dig, and nslookup (which are part of the bind-utils software package).

To maintain your DNS server correctly, you can also perform the following configuration tasks with your DNS server:

  • Logging ( You can indicate what you want to log and where log files reside.

  • Remote server options ( You can set options for specific DNS servers to perform such tasks as blocking information from a bad server, setting encryption keys to use with a server, or defining transfer methods.

You don't need to give out DNS information to everyone who requests it. You can restrict access to those who request it based on the following:

  • Access control list ( This list can contain those hosts, domains, or IP addresses that you want to group together and apply the same level of access to your DNS server. You create acl records to group those addresses, then indicate what domain information the locations in that acl can or can't access.

  • Listen-on ports ( By default, your name server accepts only name server requests that come to port 53 on your name server. You can add more port numbers if you want your name server to accept name service queries on different ports.

  • Authentication ( To verify the identities of hosts that are requesting services from your DNS server, you can use keys for authentication and authorization. (The key and trusted-keys statements are used for authentication.)


    You should already know what domain names and IP addresses are. Refer to Chapters 15, for IP addresses, and 16, for DNS information, if you need to refresh your memory.

DNS name server example

To get an idea of what you need to set up your DNS server, the following sections step you through an example of a DNS server for a domain called In the example, you're creating a DNS server for a small office network that includes the following:

  • A private, local network that resides behind a firewall.

  • A server providing DNS service and acting as a firewall between the LAN and the Internet.

In this office, other computers on the LAN are using the same Internet connection for outgoing communications. So the firewall on the server does network address translation (NAT) to enable the client computers to use the firewall as a router to the Internet. Figure 25-1 shows the configuration of the example domain.

Click To expand
Figure 25-1: The sample DNS server has a combination of public servers and private client computers.

Figure 25-1 illustrates a small office network that's sharing a single Internet connection. The DNS, Web, mail, and FTP servers all have public IP addresses. (These addresses are fictitious, so please don't try to use them.) Behind the DNS server (which is also operating as a firewall) are four client computers that have private IP addresses. (You can reuse these addresses and other private addresses that I describe in Chapter 15.)

The job of the DNS server, in this configuration, is to map the names of the public servers (,,, and into the static IP addresses that the ISP assigns ( through The DNS server also provides DNS service from the private addresses on the LAN, so each computer can reach the others on the LAN without needing to store all computer names in their own /etc/hosts file.

A key feature to this example is that it divides the view of this domain between what the outside world can see and what the computers on the private network can see. Using the view feature of BIND, I create an outside view that lets queries from the Internet find only public servers (Web, Mail, and FTP) in the domain. Then I create an inside view that lets queries from the local LAN find both the public servers and private computers (red, blue, green and yellow) in the domain.

The sections that follow describe how to set up a DNS server for the example in Figure 25-1.

Quick-starting a DNS server

The DNS server software that comes with the current Red Hat Linux is Berkeley Internet Name Daemon (BIND) version 9. To configure BIND 9, you work with the following components:

  • Configuration file (/etc/named.conf) ( The main DNS server configuration file.

  • Zone directory (/var/named) ( The directory containing files that keep information about Internet root DNS servers ( file) and information about the zones that you create for your DNS server.

  • Daemon process (/usr/sbin/named) ( The daemon process that listens for DNS requests and responds with information that the named.conf file presents.

  • Debugging tools (named-checkconf, and named-checkzone) ( What you use to determine whether you created your DNS configuration correctly.

BIND 9 also includes tools for creating DNSSEC secured zones. By using these tools, you can create and generate keys to provide authentication and secure address resolution. The example illustrated in these sections doesn't include DNSSEC configuration.

The basic steps in creating a DNS server for your example are as follows:

  • Identifying your DNS servers

  • Creating DNS Configuration files (named.conf and /var/names/*)

  • Starting the named daemon

  • Monitoring named activities

In the example configuration, you set up a primary master DNS server and a slave DNS server. The primary holds the authoritative records for the domain. The secondary is there to share requests for information about the domain, particularly in case the primary goes down.

Identifying your DNS servers

If you didn't have your DNS servers set up at the time that you purchased your domain name with a registration authority, you might have just "parked" the domain name there until you configured your DNS servers. Whenever you're ready to set up your DNS servers, return to that registration authority and provide the following information about your DNS servers:

  • DNS server IP addresses (the static IP addresses of your DNS servers, probably primary and slave)

  • DNS server host names (often, where you replace with your domain name for the primary; the slave host name is

You should register both the primary and slave DNS servers. After you update this record, that information typically takes a day or two to propagate throughout the Internet. Once your DNS servers are registered, you also need to tell the registration authority to use those DNS servers as the authority for addresses in your domain. The registration authority probably offers an online form you can fill out to identify your DNS servers.

Creating DNS configuration files (named.conf and /var/names/*)

In configuring a DNS server, you're actually creating definitions that apply to a particular zone in the public DNS tree, as well as several local zones that apply to your computer and local network. To create a useful DNS server for your example small-office environment, you have the following zones:

  • Public DNS server zone ( The DNS server is authoritative for the domain that you're serving. This zone serves the names and IP addresses for your public servers. In the example named.conf file shown in the next section, you need to replace the name with the domain that you're creating. These records become accessible to everyone on the Internet.

  • Private DNS server zone ( So each computer on the private network doesn't need to know the IP addresses for other computers on your private network, a zone is added in the example named.conf file to let the DNS server resolve these addresses. The names and IP addresses (which are private) are available only to computers on your LAN.

Note that by creating different views of these zones, different information will be returned to queries, depending on where the queries come from. For example, when someone from the Internet requests the address of the DNS server (, they will get the address However, when a query for comes from inside the LAN, the address is returned. Also, any queries from the Internet for addresses of private computers (,, and so on) are rejected.

Editing /etc/named.conf

To begin, you configure the /etc/named.conf file on the primary master DNS server representing your example domain. This example starts from the /etc/named.conf file that comes with the caching-nameserver package in Red Hat Linux. (Make sure that you install the caching-nameserver and bind packages before you continue.) Following are a few tips relating to editing the named.conf file:

  • If a statement contains substatements, make sure that you end the last substatement with a semicolon.

  • Comments can appear in the same formats that popular programming languages use. These languages include C (begin with /* and end with */), C++ (begin with // and go to the end of the physical line), and shell or Perl styles (begin from a # and go to the end of the physical line).

  • A leading exclamation mark (!) negates an element. Putting ! in a statement causes the IP address not to match the element. (Just make sure that the negation occurs before a positive match or the positive match takes precedence.)

The edited version of the /etc/named.conf file is as follows:

options {
     directory "/var/named";
acl "mylan" {
view "inside" {
     match-clients { "mylan"; };
     recursion yes;
     zone "." IN {
     type hint;
     file "";
     zone "" IN {
     type master;
     file "yourlan.db";
     zone "" {
     type master;
     file "";
     allow-transfer {; };
view "outside" {
     match-clients { any; };
     recursion no;
     zone "." IN {
     type hint;
     file "";
     zone "" {
     type master;
     file "";
     allow-transfer {; };
include "/etc/rndc.key";

The options definition lies at the beginning of the /etc/named.conf file and identifies the /var/named directory as the location where the zone files reside. The acl lines define the mylan access-control list, which consists of host computers on the local private network and the localhost (127/8). (You use this definition in the zone to enable only users on the LAN to perform reverse lookups of names of computers on the LAN.)

The DNS server is broken up into two views: inside and outside. The inside view defines how IP addresses are resolved for requests that come from the private LAN and localhost (as defined in mylan). By having recursion on (recursion yes), the named daemon will allow name server queries from any computer on the LAN. The outside view defines how queries coming from all other places (presumably, the Internet) are handled. With recursion off (recursion no), only queries from other name servers are honored. (Turning recursion off can help eliminate a common attack, where a cracker causes your server to seek information from a DNS server controlled by the cracker.)

Each zone entry in the /etc/named.conf file describes the type of server this computer is for the zone (master in all cases here, except the root zone), the database file (in /var/named) that contains records for the zone, and other options relating to the zone records. The file is set up for you by default. It identifies the locations of the Internet root servers.

I made the other zones (yourlan.db,, and for this example. For the "inside" view, the yourlan.db file lets the computers on your LAN do reverse address lookups (getting the names for IP address queries). The file contains names and addresses for all computers in your domain (including those on the local LAN). The DNS slave server for the inside view of this domain is at (Clients in your LAN would use and as DNS servers in /etc/resolv.conf.)

For the "outside" view, the file contains names and IP addresses for any computers in your domain you want to make public (computers on your private LAN are excluded). The DNS slave server for the outside view of this domain is

Notice that each zone points to a zone file in the /var/named directory. Table 25-1 shows which file in the /var/named directory each zone points to.

Table 25-1: Zones and Related Zone Files in DNS Example


Zone File ( in /var/named directory)

. (a single dot representing Internet root servers)

yourlan.db (inside view) (outside view)

Be very careful editing the /etc/named.conf file. Forgetting a semicolon is all too easy, resulting in the entire file not loading. To ensure that the /etc/named.conf file doesn't contain any syntax errors, you can run the following command (as root user):

# named-checkconf

If a syntax error is present, a message identifies the problematic line and tells what seems to be wrong with it. If the syntax is correct, continue on to create the zone files in the /var/named directory.

Setting up the zone files

The /var/named directory contains the zone files that the /etc/named.conf file names. For the example, you need to create only three zone files from scratch. You can (and should) leave the file alone.

The zone files are where most of the real work of the domain name server occurs. In the example, the file contains the basic records for the domain, including all private names and addresses. The following is an example of that file:

$TTL      86400
@         IN        SOA (
                                              2003040701  ; Serial
                                              28800       ; Refresh
                                              14400       ; Retry
                                              3600000     ; Expire
                                              86400 )     ; Minimum
; Name servers
               IN    NS
               IN    NS
; Mail server for domain
               IN    MX  10
; Public servers
ns1            IN    A
ns2            IN    A
mail           IN    A
www            IN    A
ftp            IN    A
; Private clients on the LAN
red            IN    A
blue           IN    A
green          IN    A
yellow         IN    A

The zone file for your "inside" contains resource records that include information about the zone. Your DNS server uses the TTL (time-to-live) record to tell name servers that store the information that you provide for this domain how long they can keep the information before they need to throw it out and get fresh information. The first value is the default for the entire zone, and the time is in seconds. So a value of 86,400 seconds indicates that a client that is using the information should obtain fresh records about this domain every 24 hours.

The SOA line identifies the start of authority for the domain. The at sign (@) represents the name. The dot (.) must appear at the end of the domain name. The dot represents the root server of the Internet. If you leave the dot off, your DNS server appends the domain name, so the DNS server will use the name The string indicates the e-mail address of the person who is to receive e-mail regarding the domain. (The first dot changes to an @ sign, resulting in Other information regarding the SOA record is as follows:

  • Serial:???Start with any number here. If the zone records change, increase the serial number to alert other servers that they need to get fresh data about your domain.


    If you forget to increase the serial number after changing zone records, other servers that cache this data never pick up your changes. To help remember, use the date in the serial number. The number 2003082701 would be for August 27, 2003. The 01 represents the first change made on that day.

  • Refresh:???Defines how often the slave DNS server for the zone checks for changes. (Here, 28,800 seconds represents 8 hours.)

  • Retry:???If the slave can't reach the master, it tries again after this retry interval. (Here, 14,400 seconds represents 4 hours.)

  • Expire:???If the slave can't contact the master within the expire time (3,600,000 seconds, or 1,000 hours, here), the slave discards the data.

  • Minimum:???Defines the cache time to live for negative answers. (Here, it's 86,400 seconds, or 24 hours.)

The name server (NS) records define the name servers that represent this zone. In this case, NS records define hosts with the names ns1 and ns2 in The MX record indicates the location of the mail server for the domain, so that the DNS server can direct e-mail to users in The rest of the file defines IP addresses for the private clients and public servers that are associated with the domain. Notice that the server at address serves as a client on the LAN and a slave DNS server.

For the "outside" zone we made a file using the same information from the "inside" file, with the following exceptions:

  • Removed all references to private clients on the LAN. That way, someone poking around from the Internet can't get information about your private computers.

  • Changed the addresses of the primary and slave DNS servers (ns1 and ns2) to and, respectively. In that way, only public addresses for name servers are seen by the public.

The other new file in the example is the yourlan.db file, which contains the information necessary to perform reverse IP lookups for the computers on your LAN. Here's an example:

$TTL      86400
@         IN        SOA (
                                              2002052701  ; Serial
                                              28800       ; Refresh
                                              14400       ; Retry
                                              3600000     ; Expire
                                              86400 )     ; Minimum
          IN        NS
1         IN        PTR
2         IN        PTR
3         IN        PTR
4         IN        PTR
5         IN        PTR

The SOA record identifies as the start of authority for the zone. The NS line defines as the name server for the zone. Other records are pointers to host names that reverse-map on the 10.0.0. network. The records represent the address for the DNS server ( and each of the clients on the LAN (red, blue, green, and yellow).

After you finish creating your own zone files, you can use the named-checkzone command to make sure that each zone file is correctly formed. Here is how you'd run the named-checkzone command (as root user) to check the two zone files:

# named-checkzone /var/named/
zone loaded serial 2003082701
# named-checkzone /var/named/
zone loaded serial 2003082701

The output indicates that both files are okay and that named-checkzone command is able to load the new serial numbers. In this case, the serial number represents the first serial number (01) on August 27, 2003 (2003082701).

Starting the named (DNS) daemon

To start the named daemon and see whether it's working, type the following (as root user):

# /etc/init.d/named start

If the named daemon starts successfully, clients of your DNS server should start getting information about your domain. To set the named daemon to start each time that the system boots up, type the following:

# chkconfig named on

Remember that, whenever you make changes to the named.conf or any of the zone files, you must increase the serial number for anyone checking your domain records to pick up those changes. After that, you should restart the named service too (as root user) as follows:

# /etc/init.d/named restart

If you see the Starting named message, your DNS server is probably up and running. If you want to make sure that your server is correctly resolving addresses, the following section describes some tools that you can use to check your DNS name server.

Checking that DNS is working

The best way to see if your DNS server is working correctly is to watch it in action. Here are a few commands you can use to check out your DNS server. The first example uses the host command to get the IP address for the host computer named blue in the local domain:

# host blue has address

Instead of using the simple host name to get the computer's IP address, you can enter an IP address (instead of the name) or a fully qualified host name. In the following example, the dig command is used with a domain name to get information about the addresses for a domain:

# dig
; <<>> DiG 9.2.1 <<>>
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43728
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;               IN     A
;; AUTHORITY SECTION:          604800     IN     NS          604800     IN     NS
;; Query time: 24 msec
;; WHEN: Mon Apr   6  02:12:32 2003
;; MSG SIZE  rcvd: 129

Sections in the output from dig include a question section and an authority section. The results show name server assignments and addresses associated with the domain you're querying about. The nslookup command is another tool you can use to look up domain information. In the following example, nslookup looks up the server that is resolving

# nslookup -sil


The output from the nslookup command includes the name of the computer fulfilling the request and its IP address, along with the name and address of the computer you're asking for. (The -sil prevents a message that nslookup might soon be removed from Red Hat Linux.) Try nslookup with an IP address (such as to make sure reverse lookup works.

To check the status of the named server that is running on your local system, use the same script that starts named. Type the following to check the status of your DNS server daemon:

# /etc/init.d/named status
number of zones: 5
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running

If you can't reach the computers that your DNS server is serving by name or IP address, you should make sure that each client's address records are correct. You can also try to ping each client and server computer using the full host name or IP address.

Part IV: Red Hat Linux Network and Server Setup