InformIT: Red Hat Linux 7 Unleashed > A Trivial Caching DNS

A Trivial Caching DNS

A normal Red Hat 7 installation includes a caching DNS implementation. Depending on the exact install method, and post-install configuration activities, this installation-default setup may have a flaw, making it excessively slow on any reverse DNS lookup (more on reverse DNS later in the Configuring DNS Server Master Zones section of this chapter). This problem can be verified by using telnet to access the newly installed machine. If this flaw exists, telnet will typically take 30 seconds or more to ask for the username and may time out entirely. Note that it's possible for slow telnet to be caused by flawed forward (name to number) resolution, although this is less common.

The following code contains the installation-default /etc/resolv.conf file for the new host:

search domain.cxm
nameserver 192.168.100.1

The resolv.conf file configures the DNS client, not the DNS server, even though in many cases they coexist on the same computer. The first line of resolv.conf defines domain.cxm as the client's default domain. That's the domain that's appended to machine names. The second line defines the IP address of the DNS server used by the client.

Listing 14.2 contains the installation-default /etc/named.conf file for the new host.

Example 14.2. The `/etc/named.conf` File

// generated by named-bootconf.pl

options {
        directory "/var/named";
        /*
         * If there is a firewall between you and nameservers you want
         * to talk to, you might need to uncomment the query-source
         * directive below.  Previous versions of BIND always asked
         * questions using port 53, but BIND 8.1 uses an unprivileged
         * port by default.
         */
        // query-source address * port 53;
};

//
// a caching only nameserver config
//
zone "." {
        type hint;
        file "named.ca";
};

zone "0.0.127.in-addr.arpa" {
        type master;
        file "named.local";
};

In this file, anything preceded by // or enclosed in /* */ is a comment. In English, the preceding file says the following:

All zone data files mentioned in named.conf shall be relative to directory /var/named.
zone "." is the root of the DNS tree, hints to which are given in file named.ca, which is a list of the root servers.
Any IP address in subnet 127.0.0 shall be resolved according to zone data file named.local, which is used, but not created, by the DNS server. Had it been type slave instead of type master, the file would have been created by the DNS server out of data from a zone transfer from a master zone on another computer.

When you're working with named.conf, remember that syntax is important. Make sure all quotes, braces, and semicolons are in place. If you prefer, everything between braces may be placed on a single line.

Testing Your Caching DNS

First, verify that telnet logs in properly. Run this command on another machine:


   # telnet 192.168.100.1

If it takes about a second for the username prompt to appear, so far so good. If it takes 20 seconds or more, there's still a reverse DNS problem.

NOTE

The telnet program is the "miner's canary" of reverse DNS. If there's a reverse DNS problem, telnet will hang or be extremely slow. Other programs can hang, with much worse consequences, because of bad reverse DNS. sendmail is one such program.

In the case of sendmail, it's possible the hang will prevent successful boot, requiring a repair expedition with boot and rescue disks. Other programs that are sometimes run on bootup can also hang on bad reverse DNS. This is why it's vital to have telnet working properly before you shut down or reboot the system.

If for some reason you can't repair reverse DNS before rebooting, temporarily rename /etc/resolv.conf before booting, and then rename it after.

The easiest way to repair your reverse and forward DNS resolution is to follow the instructions in the Configuring DNS Server Master Zones section later in this chapter, and then test with nslookup and maybe dnswalk. The dnswalk utility is discussed in the Troubleshooting DNS section of this chapter.

Testing Non-Local Lookup

The time has come to test the lookup capability of your caching DNS. Although a caching-only DNS server cannot provide lookup for the local network, it can refer any queries for the Internet at large to the proper Internet DNS servers. You'll remember that /var/named/named.ca was simply a list of the world's root DNS servers. These servers are "consulted" unless your cache "remembers" a lower-level server that's authoritative over the domain.

Start by verifying a good Internet connection with the ping command. Remember that DNS cannot work without a good network connection. ping the IP addresses of several Web sites that are known to be up most of the time. If you cannot ping these addresses, look for network, PPP, or routing problems.

If you're using PPP, sometimes you'll need to make a new default route corresponding to your PPP.

With PPP connections, routing is often the cause. While pppd is running, start with the ifconfig ppp0 command:


   # /sbin/ifconfig ppp0
ppp0      Link encap:Point-to-Point Protocol
          inet addr:10.37.60.188  P-t-P:10.1.1.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10

If you can ping the ppp0 inet address and the IP address following P-t-P (which stands for Point To Point) but cannot ping other Internet addresses, suspect routing. With pppd running, issue this command:


   # /sbin/route add default gw 10.1.1.1 ppp0

Obviously, substitute the P-t-P address given by the ifconfig command. Try your ping again.

Once you can ping using IP addresses, you're ready to test your caching DNS itself by accessing a URL with ping. Try this command:


   # ping www.mcp.com

If all is well, the preceding ping command will display replies from http://www.mcp.com. If not, carefully review the files and commands discussed up to this point. Once you can ping the URL, you know your caching DNS works.

If you have lynx installed, you can actually use it to browse the Web:


   # lynx http://www.mcp.com

After a suitable delay, the Macmillan Publishing Web site should appear in your lynx browser.

Addressing Special PPP Considerations

The preceding was an example. To reduce bandwidth, in real life you'd let your ISP do all your DNS by telling your DNS client that the nameserver is the ISP's nameserver. Simply put a

nameserver ###.###.###.###

line in your /etc/resolv.conf file above all other nameserver lines. The ###.###.###.### represents your ISP's primary DNS. You can also place the secondary DNS there. However, your DNS client will honor only three nameserver lines.

If you find that the additional nameserver(s) slows your normal network activities, you can have two different files you copy to /etc/resolv.conf: one for when you're online and one for when you're not.

Caching Server Summary

As installed, Red Hat 7 comes configured as a caching server. Depending on the installation procedures and post-installation configuration activities, it's possible that a reverse DNS flaw, or even a forward DNS flaw, can cause problems on programs like telnet, ftp, and sendmail. In such a case, the simple addition of reverse DNS resolution for the network subnet, or possibly forward DNS resolution for the domain, gives you a completely functioning caching-only server capable of resolving all Internet domain names, but not any that are declared locally.

Caching-only servers are the simplest and least authoritative of the three server types. The other two, master and slave, are discussed in the sections Configuring DNS Server Master Zones and "Adding a Slave DNS Server."

Configuring DNS Server Master Zones | Next Section

Previous Section