Setting Up a Domain Name System Server

The Domain Name System ( DNS ) is essentially a distributed database that translates hostnames into IP addresses (and IP addresses back to hostnames). 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 whom 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, branching in a way that looks like an upside-down tree structure. That's where you come in.

As someone who's setting up a DNS server, you're responsible for managing the hostnames 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.

Caution

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, go to the BIND 9 Administrator Reference manual at /usr/share/doc/bind-9*/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 hostnames into IP addresses. Each domain is typically represented by at least two DNS servers.

Primary (master) name server - This name server contains the master copy of 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.
Secondary (slave) name server - This name server gets all information for the domain from the primary name server. As is the case for the primary server, DNS considers the secondary's information about the domain that it serves authoritative, although the domain records can be overwritten from 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. In the upcoming "DNS name server example" section, your primary master name server is authoritative for the domain you control (as are the secondary name servers it passes its records to), 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 hostnames 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 DNS Risks

When you set up a public DNS server, you are essentially responsible for providing reliable name-to-address conversion for the clients that use that server. Because of the potential security risks in maintaining a DNS server, you should not take this responsibility lightly.

Someone breaking in to control the information in a DNS server has the potential to redirect queries to the server for addresses to sites that the intruder chooses. So, for example, if someone is trying to contact a Web server in the domain your DNS server controls, they might be entering their credit card number or other personal information into a Web site that the intruder set up to for the purpose of stealing that information.

There are several different types of attacks directed at DNS servers. DNS cache poisoning is where fraudulent addresses are attached to hostnames that are placed in a DNS server's cache. Pay-per-click frauds will infect DNS servers in such a way that the Web browsers are directed to sites that set off a string of clicks to sites that pay each time you visit them. The person using the browser may never even see any indication that he has contacted those sites.

While Bind servers seem to have a better record of resisting attacks than Microsoft servers, there is still enough risk to warrant educating yourself against such attacks. Here are a few links where you can learn more about DNS attacks:

DNS Poisoning ( http://isc.sans.org/presentations/dnspoisoning.php ) - Contains a good description of DNS poisoning and ways of dealing with it.
DNS Amplification ( www.isotf.org/news/DNS-Amplification-Attacks.pdf ) - Contains a description of DNS amplification attacks, where DDoS attacks are used recursively along a chain of DNS servers.

Refer to the ISC Bind site ( www.isc.org/sw/bind ) for security alerts that relate to DNS service with Bind.

Understanding BIND

In Fedora, Red Hat Enterprise 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 www.isc.org/sw/bind ). The particular version of BIND that I describe in this chapter is BIND 9. To use BIND as described in this section, you need to install these packages: bind, bind- utils , bind-chroot, and bind-libs. There is also a system-config-bind package that contains a graphical means of working with your DNS files.

For the latest Fedora and RHEL distributions, BIND has been configured to run in a changed root (chroot) environment (provided you install the bind-chroot package). This means that instead of having configuration files in /etc and /var/named as they always have been with BIND, they are located in /var/named/chroot/etc and /var/named/chroot/var/named instead. This is a security measure to limit the access that an intruder could gain by taking control of the named daemon. SELinux also is configured to limit access to the named and nscd daemons (see the Security Level Configuration window for details).

Note

Because /etc/named.conf file and files in the /var/named/ directory are linked to their counterparts in /var/named/chroot , you can edit those files in either directory. However, as you add zone files to the /var/named/chroot/var/named directory, you will need to create new links to those files in /var/named directory to continue to edit them from that location.

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 hostnames in your domain to IP addresses.

Note

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 file and named directory) - The /var/named/chroot/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/chroot/var/named directory contain specific zone information. The location of the chrooted DNS configuration files in Fedora and RHEL 4 ( /var/named/chroot ) is set in the /etc/sysconfig/named file.

Note

If you run BIND in a non-chrooted environment, configuration files are located in /etc/named.conf file and the /var/named directory. You must uninstall the bind-chroot package to do this.

DNS lookup tools - You can use several tools to check that your DNS server is resolving hostnames 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 (acl) - 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, and 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.)

Cross-Reference

You should already know what domain names and IP addresses are. Refer to Chapter 15 for IP addresses and Chapter 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 yourdomain.com . 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

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 yourdomain.com domain.

Figure 25-1: The sample yourdomain.com 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.)

Note

Because this is an example of how DNS works, it doesn't deal with all the complexities you might face in setting up the computing infrastructure at your company. For example, you might well want a dedicated firewall protecting your Internet connection, with the DNS server being placed with the other servers behind what is referred to as a demilitarized zone that is separated from the company LAN.

The job of the DNS server, in this configuration, is to map the names of the public servers ( www. yourdomain.com , mail. yourdomain.co m, ftp. yourdomain.com , and ns1. yourdomain.com ) into the static IP addresses that the ISP assigns ( 123.45.67.1, 123.45.67.2, 123.45.67.3 , and 123.45.67.89 , for our example). 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 Fedora and RHEL versions is Berkeley Internet Name Domain (BIND) version 9. To configure BIND 9, you work with the following components:

Configuration file ( /var/named/chroot/etc/named.conf ) - The main DNS server configuration file.
Zone directory ( /var/named/chroot/var/named ) - The directory containing files that keep information about Internet root DNS servers ( named.ca 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.

Note

Fedora and RHEL come with a GUI tool for configuring Bind called system-config-bind . (Type yum install system-config-bind to install it.) If you decide to use that tool, you need to be careful editing the Bind configuration files by hand. It is recommended that if there are changes you want to make to the named.conf file that are not supported by the system-config-bind window, you should put those changes in the /etc/named.custom file instead.

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 file and the named directory )
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 server holds the master copy of the authoritative records for the domain. The secondary server is there to share requests for information about the domain, particularly in case the primary goes down. The secondary typically gets its records from the primary server. The secondary is also considered to be authoritative in regards to the DNS records for the domains it controls.

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 hostnames (often ns1. yourdomain.com , where you replace yourdomain.com with your domain name for the primary; the slave hostname is ns2. yourdomain.com )

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. When 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/named)

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 yourdomain.com 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 ( ns1. yourdomain.com ), they will get the address 123.45.67.89. However, when a query for ns1. yourdomain .com comes from inside the LAN, the address 10.0.0.1 is returned. Also, any queries from the Internet for addresses of private computers ( red. yourdomain.com , blue. yourdomain.com , and so on) are rejected.

Editing named.conf

To begin, you configure the /var/named/chroot/etc/named.conf file on the primary master DNS server representing your example yourdomain .com domain. This example starts from the /etc/named.conf file that comes with the caching-nameserver package in Fedora and RHEL. (Make sure that you install the caching-nameserver and bind packages before you continue and make a backup copy of any configuration files you edit.) 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 !123.45.67.89 in a statement causes the IP address 123.45.67.89 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 /var/named/chroot/etc/named.conf file is as follows:

 options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; }; acl "mylan" { 127/8; 10.0.0.0/24; }; controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; }; view "inside" { match-clients { "mylan"; }; recursion yes; zone "." IN { type hint; file "named.ca"; }; zone "0.0.10.in-addr.arpa" IN { type master; file "yourlan.db"; }; zone "  yourdomain.com  " { type master; file "db.  yourdomain.com  .inside"; allow-transfer { 10.0.0.2; }; }; }; view "outside" { match-clients { any; }; recursion no; zone "." IN { type hint; file "named.ca"; }; zone "y  ourdomain.com  " { type master; file "db.  yourdomain.com  .outside"; allow-transfer { 123.45.67.2; }; }; }; include "/etc/rndc.key";

The options definition lies at the beginning of the 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 10.0.0.0 local private network and the localhost (127/8). (You use this definition in the 0.0.10.in-addr.arpa 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 to any domain (even domains that the local DNS server doesn't control) 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 for domains controlled by the local DNS server are honored. Requests for information about other domains will be rejected with a not found message. (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 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 the named directory) that contains records for the zone, and other options relating to the zone records. The named.ca file is set up for you by default. It identifies the locations of the Internet root servers.

I made the other zones (yourlan.db , db. yourdomain.com .inside, db. yourdomain.com .outside and 0.0.10.in-addr.arpa ) 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 db. yourdomain .com.inside 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 10.0.0.2. (Clients in your LAN would use 10.0.0.1 and 10.0.0.2 as DNS servers in /etc/resolv.conf .)

For the "outside" view, the db. yourdomain .com.outside 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 123.45.67.2.

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

Table 25-1: Zones and Related Zone Files in DNS Example
Open table as spreadsheet
*Zone*	*Zone File (located in the /var/named/chroot/var/named directory)*
. (a single dot representing Internet root servers)	named.ca
0.0.10.in-addr.arpa	yourlan.db
yourdomain.com (inside view)	db.yourdomain.com.inside
yourdomain.com (outside view)	db.yourdomain.com.outside

Be very careful editing the named.conf file. Forgetting a semicolon is all too easy, resulting in the entire file not loading. To ensure that the 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 informs you what seems to be wrong with it. If the syntax is correct, continue to create the zone files in the /var/named directory.

Setting Up the Zone Files (Inside)

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

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

 $TTL 86400 @ IN SOA  yourdomain.com  . hostmaster.  yourdomain.com  . ( 2006042701 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400) ; Minimum ; Name servers IN NS ns1.  yourdomain.com  . IN NS ns2.  yourdomain.com  . ; Mail server for domain IN MX 10 mail.  yourdomain  .com. ; Public servers ns1 IN A 10.0.0.1 ns2 IN A 10.0.0.2 mail IN A 123.45.67.2 www IN A 123.45.67.3 ftp IN A 123.45.67.4 ; Private clients on the LAN red IN A 10.0.0.2 blue IN A 10.0.0.3 green IN A 10.0.0.4 yellow IN A 10.0.0.5 ; EOF

The zone file for your "inside" yourdomain .com 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 yourdomain .com. 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 yourdomain .com. yourdomain .com . The hostmaster. yourdomain .com 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 hostmaster@ yourdomain .com ). 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.

Caution

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 2006042701 would be for April 27, 2006. 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 (here, 3,600,000 seconds, or 1,000 hours), 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 yourdomain.com . 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 yourdomain.com . 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 10.0.0.2 serves as a client on the LAN and a slave DNS server.

Setting Up the Zone Files (Outside)

For the "outside" yourdomain.com zone we made a db. yourdomain.com .outside 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 123.45.67.1 and 123.45.67.2, respectively. In that way, only public addresses for name servers are seen by the public. (Of course, you need to use your own public IP addresses instead of the examples 123.45.67.1 and 123.45.67.2.)

Setting Up the Zone Files (Reverse Lookup)

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 ns1.    yourdomain    .com hostmaster.    yourdomain    .com. (   2006042701 ; Serial   28800 ; Refresh   14400 ; Retry   3600000 ; Expire   86400) ; Minimum   IN NS ns1.    yourdomain    .com   1 IN PTR    yourdomain    .com.   2 IN PTR red.    yourdomain    .com.   3 IN PTR blue.    yourdomain    .com.   4 IN PTR green.    yourdomain    .com.   5 IN PTR yellow.    yourdomain    .com.   ; EOF

The SOA record identifies 0.0.10.in-addr.arpa. as the start of authority for the zone. The NS line defines 0.0.10.in-addr.arpa. as the name server for the zone. Other records are pointers to hostnames that reverse-map on the 10.0.0. network. The records represent the address for the DNS server ( yourdomain. com ) 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 formed correctly. Here is how you'd run the named-checkzone command (as root user) to check the two yourdomain.com zone files (be sure to type each command on one line, even though each is shown here on two):

 #  named-checkzone  yourdomain.com    /var/named/chroot/var/named/db.  yourdomain.com  .inside  zone yourdomain.com/IN: loaded serial 2006042701 OK #  named-checkzone  yourdomain.com    /var/named/chroot/var/named/db.  yourdomain.com  .outside  zone yourdomain.com/IN: loaded serial 2006042701 OK

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 April 27, 2006 (2006042701).

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

Then you should consider adding the server's own local address to its own /etc/resolv.conf file. For example, the /etc/resolv.conf file could include the following:

 search  yourdomain  .com nameserver 127.0.0.1

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 next section, "Checking that DNS is working," describes some tools that you can use to check your DNS name server.

Checking that DNS is Working

The best way to verify whether 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  blue.  yourdomain.com  has address 10.0.0.3

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

 #  dig  yourdomain.  com  ; <<>> DiG 9.3.2 <<>>  yourdomain  .com ;; 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 ;; QUESTION SECTION: ;yourdomain.com. IN A ;; AUTHORITY SECTION: yourdomain.com. 604800 IN NS ns1.yourdomain.com. yourdomain.com. 604800 IN NS ns2.yourdomain.com. ;; Query time: 24 msec ;; SERVER: 10.0.0.1#53(10.0.0.1) ;; WHEN: Mon Oct 9 02:12:32 2006 ;; 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 ftp .yourdomain.com :

 #  nslookup -sil ftp.  yourdomain.  com  Server: 123.45.67.1 Address: 123.45.67.1#53 Name: ftp.  yourdomain  .com Address: 123.45.67.4

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 option prevents a message that nslookup might soon be removed from Fedora and RHEL.) Try nslookup with an IP address (such as 10.0.0.1) 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 recursive clients: 0/1000 tcp clients: 0/100 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 hostname or IP address.