Troubleshooters.Com presents

November 1998 Troubleshooting Professional Magazine

Hot off the Presses: Bind Version 8. WARNING!!!

Bind (the protocol behind DNS) has gone from version 4 to version 8 since this document was written. Depending on your Linux distro, you may have either. A version 4 setup (which is what is described in this tutorial) WILL NOT work with version 8 bind (a version 8 named program). When moving up to version 8, your best bet is to start from scratch, using your old setup files only as a guide to IP numbers and host/domain names.

Red Hat 5.1 used version 4. Red Hat 5.2 uses version 8.

Click here (then click back button to return) for an instruction document for version 8 DNS setup (the one that uses /etc/named.conf instead of /etc/named.boot). If you're running version 4 (the one using /etc/named.boot instead of /etc/named.conf) then you're already on the right page. The document you're now viewing describes setup of version 4 bind.

Graduate Study: Setting Up DNS

By Steve Litt, Steve Litt's email address

I'd like to thank Jeff Moe for the authoritative (no pun intended) information on his website, and his email help when I got stuck. Jeff can be reached at jeff@verinet.com. A link to his website appears in the URLs section.

So far you've built a Command-Line Linux, written a couple simple programs, gotten X Windows working, set up a Linux network and accessed it with a Win98 machine, installed one or more websites (accessible from any machine on the network) complete with CGI, and made a replica of your ISP using virtual hosting. You now have enough knowledge to confidently approach a simple Linux troubleshooting situation. But some of you might want to go farther.

Let's talk about DNS. You might have heard DNS stands for Domain Name System. Don't believe it. DNS stands for Darned Nasty Setup. It's fraught with booby traps and landmines. It's not for the weekend warrior.

If you want to go for it and set up your Linux machine as a DNS server, then my job in this article is to get you through it with as little cursing and hair pulling as possible. We'll do DNS in four stages:

Preparation
Hello World A: Recognize the Server Name
Hello World B: Recognize Virtual Domain Names
Hello World C: Add Reverse DNS Lookup

Preparation

Just like Troubleshooting, the first step here is Get the Attitude. The best way to do that is to assemble all our tools, make sure we're starting with as clean a slate as possible, and know what to do when things go wrong.

The tools are numerous. First, you need an editor to use in Linux. Linux comes with vi, emacs (and if you understand emacs you're smarter than me), jed, and Wordstar-like joe. Another alternative is a Win command line batch file that FTP's the file back to your Win machine, pulls it up in your editor of choice, then puts it back in the right place in Linux when done. This has some limitations because you can't FTP in as user root. Additionally, you can manually FTP it to your Win machine, use your favorite editor, open a telnet session, do an su to become root, run vi, empty out the file in vi, go into insert mode, then in telnet go edit/paste. Sounds like a lot of work, but it's not that bad. Anyway, just find a relatively painless way to edit files.

You need to master your diagnostic tools. Ping, nslookup and your browser, in that order. Ping is the most forgiving of defective DNS setups, so if you can't ping a URL, it's likely you can't pull it up in nslookup or a browser either. A successful ping will look something like this:

C:\>ping www.troubleshooters.cxm Pinging troubleshooters.mydomain.cxm [192.168.100.113] with 32 bytes of data: Reply from 192.168.100.113: bytes=32 time=1ms TTL=64 Reply from 192.168.100.113: bytes=32 time<10ms TTL=64 Reply from 192.168.100.113: bytes=32 time<10ms TTL=64 Reply from 192.168.100.113: bytes=32 time<10ms TTL=64 Ping statistics for 192.168.100.113: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 1ms, Average = 0ms C:\>

Note that troubleshooters.mydomain.cxm is the host (or in this case virtual host) associated with alias www.troubleshooters.cxm, while 192.168.100.113 is that virtual host's IP address.

A successful nslookup on the Linux box would look something like this:

[root@linuxhost myuid]# nslookup www.troubleshooters.cxm Server: linuxhost.mydomain.cxm Address: 192.168.100.3 Name: troubleshooters.mydomain.cxm Address: 192.168.100.113 Aliases: www.troubleshooters.cxm [root@linuxhost myuid]#

Note that the server is linuxhost.mydomain.cxm, the DNS server. Address 192.168.100.3 is defined in /etc/resolv.conf, and must be the IP address of the DNS server, your Linux machine. If /etc/resolv.conf is missing (and this is OK), the server address will be listed as 0.0.0.0, but this is OK. The Name field is the host (or in this case virtual host) associated with alias www.troubleshooters.cxm, while 192.168.100.113 is that virtual host's IP address.

Nslookup can have an optional second argument, the IP address of the DNS server. That allows you to do lookups when some part of the system configuration is lying about where the DNS server resides. For instance, if you know your DNS server is at 192.168.100.3, but the single argument nslookup call hangs, times out or isn't producing some meaningful output, some part of the system thinks the DNS server is somewhere other than 192.168.100.3. No problem, use 192.168.100.3 as the second argument to override the IP the system thinks is the DNS server. If that doesn't work, you need to wonder whether 192.168.100.3 really is acting as a DNS server.

The program that allows a Linux machine to act as a DNS server is called named. You can make sure named is running with the following command:

ps ax | grep named

If named isn't running on the server that's supposed to be the DNS host, you need to fix that before anything else. Since named is run during bootup, diagnose why it isn't being run.

If nslookup isn't producing good results (especially if it hangs or times out), it's unlikely your setup will work right at the browser level, although unfortunately, due to browser caching, a new problem might not show up on your browser immediately or might look intermittent on your browser.

Using your browser as a tool is a tricky proposition, because it has cache. A change on your server might not be recognized at the browser level until you clear cache.

Absolute and relative names and numbers

In the domain DNS configuration file (the one with the SOA on the DNS server machine's domain (not IP)), any names are assumed relative to the domain left of the SOA, unless the name ends in a period. For instance, if the domain is mydomain.cxm, the line

linuxhost.mydomain.cxm.            IN   A    192.168.100.3

is absolute because of the period after the com, while

linuxhost                          IN   A    192.168.100.3

is relative to mydomain.cxm, and actually means the same as the first one (linuxhost.mydomain.cxm). However, be on guard for the forgotten period, as in

linuxhost.mydomain.cxm             IN   A    192.168.100.3

(note the lack of a period) which actually transforms to linuxhost.mydomain.cxm.mydomain.cxm.

Be on guard also for side effect bugs from relative CNAMES. For instance, check this out:

linuxhost.mydomain.cxm.           IN A     192.168.100.3
troubleshooters.mydomain.cxm.     IN A     192.168.100.113
www                               IN CNAME linuxhost.mydomain.cxm.

www.troubleshooters.cxm.          IN CNAME troubleshooters.mydomain.cxm.
troubleshooters.cxm.              IN CNAME troubleshooters.mydomain.cxm.

This will produce an oddball situation where every second ping www.troubleshooters.cxm produces an IP of 192.168.100.3, with the alternate pings producing 192.168.100.113. Note, however, that pinging troubleshooters.cxm (without the leading www.) will always produces the correct result, 192.168.100.113. I can only guess that the www in the www.troubleshooters.cxm statement is being expanded to linuxhost.mydomain.cxm??? Be very careful about relative aliasing. I prefer to go absolute all the way, at least for simple applications like this.

Common mistakes:

Always begin by rounding up the usual suspects:

Forgot to put a period on an entity meant to be absolute in a DNS configuration file.

Causes the entity not to be found.

Forgot to incriment a serial number in an SOA (start of authority).

Causes a change in a configuration file not to be recognized.

Made www a relative IN CNAME entity instead of making it absolute with a trailing domain and period.

Causes a maddening intermittence at the browser level on URLs beginning with www (that's how you diagnose it). At the ping level, this problem manifests itself, again only on URLs containing www, as showing the correct virtual IP address on every odd number pings (first, third ...), with the server's IP address showing on the even number pings.

An /etc/resolv.conf exists with nameserver IP address, but there's no reverse DNS file to look it up, or the reverse DNS file is defective.

Manifests itself in a variety of ways, including hanging or timeout on nslookup, or hanging or extreme load times for bootup processes (especially amd). If you can make the problem less severe or fix it by renaming /etc/resolv.conf, take a look at your reverse DNS lookup file.

Forgot to restart httpd, restart named, and clear the browser's cache.

Forgetting to do these things can lead you down false paths, causing the "problem to escape from the box". When in doubt, reboot, and close all browsers after clearing cache, then reopen the browser after the Linux machine is back up. Yes, this takes a lot of times, but a problem that gets out of the box can consume hours or even days. When ping and nslookup seem to produce very different results from the browser, suspect this.

Forgot to uncomment a line (semicolons are comment marks).

Various problems.

Accidentally left spaces at the start of an IN A, IN SOA or IN CNAME line.

Leading space at the start of an IN A or IN CNAME line causes inability to ping to the name (and obviously if it can't be pinged, it can't be nslookuped or browsed to either). Leading space at the start of an IN SOA line causes a "Non-authoritative answer" response from nslookup, which indicates a subtle problem causing troubleshooting grief down the road.

Wrong search path for name resolution in linuxconf->Config->Networking->Client_tasks->Host_name_search_path. It should be dns, not hosts, dns. The search of hosts can take a long time if everything isn't set up just right, or if the hosts file lists servers that can't resolve names.

Wrong path can lead to long browser delays, an even timeouts, especially in new URLs. Note that a wrong search path probably WILL NOT cause a noticable problem with ping or nslookup, making it especially insideous.

When things really go wrong:

A defective DNS setup can cause your machine not to boot completely, possibly locking you out of the machine and preventing you from fixing the problem. If you haven't yet read it, make sure you read and understand the section on Boot Floppies -- Getting Back Into a Locked Up System. Many times you can get the system to boot by renaming /etc/resolv.conf. Other times you'll need to comment out a service that run on bootup. Here's how:

On bootup, after most of the system is up, shellscript /etc/rc.d/rc runs a loop that incriments a counter, which runs all the "start scripts" for the given level (and we're using the default level 3. The start scripts (and the kill scripts) for level 3 are located in /etc/rc.d/rc3.d. The start scripts all begin with the letter S, followed by a number, followed by other letters describing their function. So the loop will run anything starting with S01, followed by S02, continuing on up. This is how all the start scripts are run in the correct order. To comment out one of these scripts, simply go into the /etc/rc.d/rc3.d directory and rename the script by putting the letters REM_ in front of the script filename. In other words, to comment out S72amd, you'd rename it to REM_S72amd, and the next time you boot amd wouldn't start.

When the machine hangs at a specific place during bootup and you want to comment out the particular service, if possible get into a session via telnet or Alt-F2 and see what start script hung. Use this command:

ps ax

Write down the start script and the pid number. Then kill it with the kill command, using the pid as an argument. If that was the service that hung the startup, the boot should proceed. In that case, to (hopefully temporarily) comment out that start script, just rename it as described above.

Start with a clean slate:

Correct DNS configuration is an order of magnitude trickier than the subjects discussed up to this point. I'd highly recommend you reinstall Linux from scratch, let the configuration program do the network configuration, and reproduce all the steps in the previous articles, getting everything working perfectly. The two hours you spend doing this will save you hours or days of troubleshooting by reducing the number of variables you need to consider. And please remember to get your virtual hosting set up as described in the Make a Replica of Your ISP article. Test with a browser to make sure each IP address maps to its assigned website, and that all features work except CGI dependent on domain names or interfacing with email or newsgroups.

Hello World A: Recognize the Server Name

Note: In all the following DNS configuration files, a line starting with a semicolon is a comment.

When done correctly, this simplest of Hello World DNS setups should simply give you the ability to call the Linux machine by name instead of number. For instance, if it's called linuxhost.mydomain.cxm, you should be able to successfully do the following:

ping linuxhost.mydomain.cxm

nslookup linuxhost.mydomain.cxm

browse to http://linuxhost.mydomain.cxm (this should bring up the default apache page).

linuxconf

Now that we're enabling DNS, we need to tell our Linux host to resolve names in DNS. Do that with linuxconf->Config->Networking->Client_tasks->Host_name_search_path, and check the radio button marked (*)dns. Red hat defaults this to (*) hosts, dns. The Red Hat default will cause long waits, and possibly timeouts, in browsers the first time a new domain is accessed.

/etc/resolv.conf

Rename it. The Hello World A configuration should not have a /etc/resolv.conf

/etc/named.boot

Named.boot enumerates the files to configure various lookups. The cache file is a standard one put out by Internic, and created by the Linux installation program, and need not be changed. Named.local just defines lookups on the loopback. The only real content here is named.mydomain.cxm, which handles all lookups concerning domain mydomain.cxm.

; /etc/named.boot: Entry data for DNS server on this machine


; directory containing subsequent DNS configuration files
directory                              /var/named


; /var/named/named.ca is configuration file for cached queries. It
; contains the root DNS servers worldwide. Of course, it's

; in the /var/named directory, as specified by the directory
; line above. Note the period between the
; words cache and named.ca.
cache           .                      named.ca


; /var/named/named.local defines lookups on the loopback 127.0.0.1 IP
; /note the reversal of the numbers 127.0.0, and the placement of the
; periods.
primary         0.0.127.in-addr.arpa   named.local


; /var/named/named.mydomain.cxm defines lookups on this dns server,
; linuxhost.mydomain.cxm.
primary         mydomain.cxm           named.mydomain.cxm

/var/named/named.mydomain.cxm

Note first of all that the filename could be anything, as long as it's the same as the filename mentioned in /etc/named.boot.

CAUTION: It's quite easy to accidentally leave leading blanks at the beginning of an IN A line or an IN CNAME line. This is not allowed -- it will cause an inability to ping, as well as any other kind of access. My tests indicated you could have leading blanks at the start of the IN SOA line, but it will cause subtle problems including non-authoritative lookups. Best practice is to allow leading blanks only on the IN SOA argument lines (serial number, etc). Otherwise, do not have leading blanks. Note that if you paste into a telnet session from this web page, it will put a single leading blank on each line. Best practice is to delete each of those single leading blanks.

Note: After making DNS configuration changes, an alternative to rebooting is to restart both named and httpd. It's much quicker, although it isn't quite as sure. You can put a restart command in /usr/bin to do that. Here are the contents of the restart command:

kill -HUP `cat /var/run/httpd.pid` kill -HUP `cat /var/run/named.pid` Be sure to chmod /usr/bin/restart executable to all (chmod a+x /usr/bin/restart). Remember that the tickmarks surrounding the cat clause are backticks ( ` ), not single quotes ( ' ). On most keyboards, the backtick (also called grave accent) is found on the same key as the tilde ( ~ ), near the upper right of the keyboard.

; named.mydomain.cxm:
; DNS definitions for this DNS server.
; First, start with the SOA (start of authority) statement,
; which says that linuxhost.mydomain.cxm is the host that has
; authority over naming in the mydomain.cxm domain.
; Note serial number line 1998100501, which must be increased

; every time a change is made to this file. Its YYYYMMDD## format
; allows 100 changes per day, which should be plenty.
; If this number isn't increased, changes to this file may not be
; recognized downstream.
mydomain.cxm. IN SOA   linuxhost.mydomain.cxm. hostmaster.mydomain.cxm. (
                                             1998100501
                                             10800
                                             3600
                                             604800
                                             86400
                                             )

; Now define this machine as a domain server
                     IN      NS      linuxhost.mydomain.cxm.

; Finally, associate this name server machine with an IP address
linuxhost.mydomain.cxm.            IN   A    192.168.100.3

With those changes made, reboot the machine. Ping linuxhost.mydomain.cxm should output IP address 192.168.100.3, as should nslookup linuxhost.mydomain.cxm. If not, troubleshoot. Finally, put http://linuxhost.mydomain.cxm in a browser window, after clearing the browser's cache. It should pull up the Apache default page at /home/http/index.html.

Hello World B: Recognize Virtual Domain Names

Hello World A got us over the hump by having DNS do the single translation between the machine's name and its IP address. That's useful in giving us confidence and in making sure named is doing its job. But in the real world, it's not enough. We need to be able to translate all the virtual domain names your Linux computer needs to recognize into IP addresses. Before we continue, let's make a few definitions:

Phrase	Definition
Virtual Host	An IP address, distinct from that of the machine, which points to its own document root directory containing html. These extra IP addresses are set up in linuxconf->config->networking->server tasks->IP aliases for virtual hosts->eth0. The mapping between those IP addresseses and their document root directories are defined in <virtualhost> blocks near the bottom of /etc/httpd/conf/httpd.conf.
Virtual Domain	A (usually 3 level) domain name pointing to a virtual host. For instance, if the domain of your Linux machine is mydomain.cxm and the machine is called linuxhost.mydomain.cxm mapping to 192.168.100.3, a virtual domain of nag.mydomain.cxm might map to virtual host 192.168.100.148. This mapping is defined by the IN A statements in named.mydomain.cxm.
Alias Domain	This is a domain name, completely different from your Linux machine's name, mapping to a Virtual Domain. For instance, I can have alias domains www.troubleshooters.cxm, www.problemsolving.cxm and www.stevelitt.cxm all pointing to virtual domain troubleshooters.mydomain.cxm, and also have alias domains www.nag.cxm and www.netadminguide.cxm both mapping to nag.mydomain.cxm. The mappings from alias domains to virtual domains are contained in the IN CNAME statements in named.mydomain.cxm.

What We Will Build in the Hello World B DNS Exercise

We'll be building an ISP-like intranet with two websites, pointed to by several domain names:
IP address

Alias Domains (Map to a Virtual Domain by a IN CNAME statement in /var/named/named.mydomain.cxm and enabled by a primary entry in /etc/named.boot.)	Virtual Domain (Maps to the IP address by an IN A statement in /var/named/named.mydomain.cxm file.)	IP address (Maps to the Home Directory by a <VirtualDomain> block in /etc/httpd/conf/httpd.conf), and enabled by an entry in linuxconf's config-> Networking-> server tasks-> IP aliases-> eth0	Home directory (Maps to a web page by the content of this directory)	Web Page
www.mydomain.cxm	linuxhost.mydomain.cxm	192.168.100.3 (Note: this is the actual IP address of the machine.)	/home/httpd/html	Apache's "Test Page for Red Hat Linux's Apache Installation"
www.troubleshooters.cxm troubleshooters.cxm www.problemsolving.cxm problemsolving.cxm www.stevelitt.cxm stevelitt.cxm	troubleshooters.mydomain.cxm	192.168.100.113	/web/ sites/ troubleshooters.cxm	A small sample page created by you, to test the system.
www.nag.cxm nag.cxm www.netadminguide.cxm netadminguide.cxm	nag.mydomain.cxm	192.168.100.148	/usr/doc/LDP/nag	The Network Administrator's Guide documentation that comes with Red Hat Linux.

Virtual Domains: General Principles

In principle, moving from Hello World A to Hello World B is fairly simple. Assuming your virtual host IP's have already been set up and pull up the correct website, here's what you do:

For each Virtual Domain (not Alias Domain, but Virtual Domain, i.e. troubleshooters.mydomain.cxm):

Insert an IN A statement in /var/named/named.mydomain.cxm, associating a new three level url (with the first and second levels being mydomain.cxm) with the appropriate IP address. As a matter of custom, you'll probably make the level 3 name conform to the second level name of the main alias domain you want to assign to this virtual domain. For instance, if the intent is to host alias www.troubleshooters.cxm, it's most convenient to name associated virtual domain troubleshooters.mydomain.cxm.

For each Alias Domain (i.e. www.troubleshooters.cxm):

Insert a primary line in /etc/named.boot associating the alias domain with named.mydomain.cxm. This directs inquiries on the alias domain (i.e. troubleshooters.cxm) to the file containing the proper alias mappings.
Insert an IN CNAME line into /var/named/named.mydomain.cxm mapping the domain, both with and without a preceeding www., to the proper virtual domain.

In addition to the above, you'll insert into /var/named/named.mydomain.cxm IN CNAME lines mapping alias www.mydomain.cxm to linuxhost.mydomain.cxm, and ns1.mydomain.cxm to linuxhost.mydomain.cxm. These must be absolute -- strange, seemingly intermittent or even odd/even problems can occur if www is mapped relatively.

Here's the new /etc/named.boot with the addition of troubleshooters.cxm, problemsolving.cxm, stevelitt.cxm, nag.cxm, and netadminguide.cxm.

; /etc/named.boot: Entry data for DNS server on this machine ; directory containing subsequent DNS configuration files directory /var/named ; /var/named/named.ca is configuration file for cached queries. It ; contains the root DNS servers worldwide. Of course, it's ; in the /var/named directory, as specified by the directory ; line above. Note the period between the ; words cache and named.ca. cache . named.ca ; /var/named/named.local defines lookups on the loopback 127.0.0.1 IP ; /note the reversal of the numbers 127.0.0, and the placement of the ; periods. primary 0.0.127.in-addr.arpa named.local ; /var/named/named.mydomain.cxm defines lookups on this dns server, ; linuxhost.mydomain.cxm. primary mydomain.cxm named.mydomain.cxm

;************************************************************************* ;*** BELOW THIS LINE IS THE CODE ADDED TO HELLO A TO IMPLEMENT HELLO B *** ;************************************************************************* ; Each virtual domain and clone domain (different Domain, same IP ; must be referenced here and directed to the DNS server's ; file in directory /var/named. Otherwise, even though these ; domains are defined in ; named.mydomain.cxm, that file won't be consulted for ; those domains (in the absense of an entry here in named.boot) primary troubleshooters.cxm named.mydomain.cxm primary problemsolving.cxm named.mydomain.cxm primary stevelitt.cxm named.mydomain.cxm primary nag.cxm named.mydomain.cxm primary netadminguide.cxm named.mydomain.cxm

Here's the new named.mydomain.cxm file, with the addition of Virtual Domains mapped to Virtual Hosts, and Alias Domains mapped to Virtual Domains.

; named.mydomain.cxm: ; DNS definitions for this DNS server. ; First, start with the SOA (start of authority) statement, ; which says that linuxhost.mydomain.cxm is the host that has ; authority over naming in the mydomain.cxm domain. ; Note serial number line 1998100501, which must be increased ; every time a change is made to this file. Its YYYYMMDD## format ; allows 100 changes per day, which should be plenty. ; If this number isn't increased, changes to this file may not be ; recognized downstream. mydomain.cxm. IN SOA   linuxhost.mydomain.cxm. hostmaster.mydomain.cxm. (                                              1998100501                                              10800                                              3600                                              604800                                              86400                                              ) ; Now define this machine as a domain server                      IN      NS      linuxhost.mydomain.cxm. ; Finally, associate this name server machine with an IP address linuxhost.mydomain.cxm.            IN   A    192.168.100.3

;************************************************************************* ;*** BELOW THIS LINE IS THE CODE ADDED TO HELLO A TO IMPLEMENT HELLO B *** ;*************************************************************************

; Now, associate each "virtual domain" with an IP address. ; Note that the document root directory for each IP is contained ; in /etc/httpd/httpd.conf, in a "VirtualHost" block. ; Note also that these IP addresses come out of a block of ; IP addresses defined in the linuxconf program as follows: ; config->Networking->Server tasks->IP aliases for virtual hosts->eth0 troubleshooters.mydomain.cxm. IN   A    192.168.100.113 nag.mydomain.cxm.              IN   A    192.168.100.148 ; Define aliases for www and name server 1, both of which are ; simply this machine. To prevent subtle bugs, use ONLY fully ; qualified names (ending with period). www.mydomain.cxm.        IN      CNAME   linuxhost.mydomain.cxm. ns1.mydomain.cxm.        IN      CNAME   linuxhost.mydomain.cxm. ; For each domain over which this server has authority, use ; an alias to point it to the proper "virtual domain". For each ; domain, make sure to alias both with and without the www. This ; way, web surfers can hit it either way. To prevent subtle bugs, ; use ONLY fully qualified names (ending with period).            www.troubleshooters.cxm.    IN      CNAME   troubleshooters.mydomain.cxm. troubleshooters.cxm.        IN      CNAME   troubleshooters.mydomain.cxm. www.problemsolving.cxm.     IN      CNAME   troubleshooters.mydomain.cxm. problemsolving.cxm.         IN      CNAME   troubleshooters.mydomain.cxm. www.stevelitt.cxm.          IN      CNAME   troubleshooters.mydomain.cxm. stevelitt.cxm.              IN      CNAME   troubleshooters.mydomain.cxm. www.nag.cxm.                IN      CNAME   nag.mydomain.cxm. nag.cxm.                    IN      CNAME   nag.mydomain.cxm. www.netadminguide.cxm.      IN      CNAME   nag.mydomain.cxm. netadminguide.cxm.          IN      CNAME   nag.mydomain.cxm.

Once you've completed this work, reboot the Linux machine and test. A ping www.troubleshooters.cxm command should consistently bring back 192.168.100.113, while ping www.nag.cxm should consistently bring back 192.168.100.148. On the Linux machine, a nslookup www.nag.cxm should produce this result:

[root@linuxhost myuid]# nslookup www.nag.cxm Server: linuxhost.mydomain.cxm Address: 0.0.0.0 Name:    nag.mydomain.cxm Address: 192.168.100.148 Aliases: www.nag.cxm [root@linuxhost myuid]#

Note that the 0.0.0.0 server address is caused by the lack of a /etc/resolv.conf, but this is OK.

Now clear your browser cache, close all sessions of your browser, and browse your new domains such as http://www.stevelitt.cxm, http://www.nag.cxm, http://troubleshooters.cxm, etc. Note that it should bring up the right pages. Note that if your home page is a domain switcher (a CGI device to make a single IP address look like several different websites, depending on which domain name is typed in), the domain switcher should work perfectly.

If you can't visualize a domain switcher and would like to see one in action, fire up your modem, and browse to www.troubleshooters.com, www.problemsolving.com, and www.stevelitt.com (note these are .com, the real internet first level domain, and you must be connected to the Internet). Although at first they'll look like different sites, if you go up directories and down directories you'll see that they're all at the same IP with the same document root. My domain switcher was originally authored by Web Developer Steve McCausland, and I added a few features of my own.

Assuming everything's working, your DNS is completely set up for http (of course not email or news), except for one thing: There's no reverse DNS. Read on...

Hello World C: Add Reverse DNS Lookup

Reverse DNS lookups are used often. Nslookup uses reverse DNS lookup to achieve the single argument version of its lookup. It looks in /etc/resolv.conf for the nameserver line, translates the nameserver address to a fully qualified domain name, and uses that fully qualified domain name as the DNS server. That's why we couldn't have a /etc/resolv.conf in the hello A and B -- reverse lookup on the 192.168.100.3 would have failed, and the nslookup would have "hung" until it timed out. To get an nslookup to work with a /etc/resolv.conf but without reverse lookup, we would have had to override the /etc/resolv.conf nameserver line with the second argument of the nslookup command.

I've heard reverse lookup is also used in Telnet. Furthermore, lack of reverse lookup can cause certain timeouts or complete hangs on bootup. Witness the amd service when there's a /etc/resolv.conf but no reverse DNS. Last but not least, many log analysis programs will show you the domains visitors came from, instead of just their IP numbers, if reverse DNS is set up. I'm not sure how valuable this is since half your hits will be from AOL people, but...

Once we've gotten DNS Hello World B to work, achieving DNS Hello World C, reverse DNS, is fairly straightforward. We need to:

make a proper reverse DNS configuration file,
add it as a primary in /etc/named.boot,
and construct the proper 2 line /etc/resolv.conf.

Let's call the reverse DNS file named.192.168.100.3. Here it is:

100.168.192.in-addr.arpa.   IN      SOA     linuxhost.mydomain.cxm. hostmaster.mydomain.cxm. (
                                              1998100504
                                              10800
                                              3600
                                              604800
                                              86400
                                              )

                      IN      NS      linuxhost.mydomain.cxm.

3     IN      PTR     linuxhost.mydomain.cxm.

113   IN      PTR     troubleshooters.mydomain.cxm.

148   IN      PTR     nag.mydomain.cxm.

You'll notice several things:

Just like in the forward DNS file, the SOA (Start Of Authority) statement has a serial number that must be incrimented every time this file is changed.
The punctuation in the SOA is tricky. Make sure you get it right.
Each of the 3 reverse pointers points to a genuine virtual domain, not to an alias (i.e. www.troubleshooters.cxm) domain.
Each of the 3 reverse pointers is relative, with no period and only the final byte of the IP. They didn't seem to work right for me if I made them absolute.
This DOES NOT map a number back to an alias domain. It maps it back to a virtual domain.

Next we tell /etc/named.boot to reference this file (named.192.168.100.3) for reverse lookup, by adding this single line to named.boot:

primary         100.168.192.in-addr.arpa   named.192.168.100.3

Put that line after the primary lines for the Alias domains, with a suitable comment (Reverse DNS lookup configuration file) above it. Note that only the high order bytes of the IP address are used, and they are put in reverse order in the in-addr.arpa clause.

Finally, we install the proper /etc/resolv.conf, as shown below:

domain mydomain.cxm nameserver 192.168.100.3

If you've done everything right, the nslookup 192.168.100.113 command should bring back troubleshooters.mydomain.cxm as shown:

[root@linuxhost myuid]# nslookup 192.168.100.113 Server: linuxhost.mydomain.cxm Address: 192.168.100.3 Name: troubleshooters.mydomain.cxm Address: 192.168.100.113 [root@linuxhost myuid]#

If not, use ping, nslookup, your browser, and documentation to narrow down the problem.

dnswalk: The Ultimate Test

This is beyond the scope of this tutorial, but if you really want to test the daylights out of your DNS setup, procure David Barr's dnswalk DNS debugger at http://www.cis.ohio-state.edu/~barr/dnswalk/. A link is located in the URL's section at the bottom of this magazine. Since dnswalk relies on Michael Fuhr's Net::DNS, a Perl module you can get at http://www.dimensional.com/~mfuhr/perldns/Net-DNS-release.tar.gz (link in URL's section). You'll need to gunzip and tar --extract both (into their own directories, of course), and build Net::DNS. See the Get DBI::DBD Working section of the article on building a web app for general instructions on installing a new Perl module (then click your browser's back button to come back).

Once dnswalk is installed, just go

perl dnswalk mydomain.cxm.

to invoke it and see all your mistakes. The trailing period is essential. Note that it will correctly deduce that you've committed a no-no by having only 1 DNS server, but of course if you have only one Linux machine you have little choice. If you change the top line of the dnswalk file to point to where your Perl is, you can dispense with the perl command and just do this:

./dnswalk mydomain.cxm.

Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist and of the Universal Troubleshooting Process courseware. He can be reached at Steve Litt's email address.

Troubleshooters.Com presents

November 1998 Troubleshooting Professional Magazine

Hot off the Presses: Bind Version 8. WARNING!!!

Graduate Study: Setting Up DNS

By Steve Litt, Steve Litt's email address

Preparation

Absolute and relative names and numbers

Common mistakes:

When things really go wrong:

Start with a clean slate:

Hello World A: Recognize the Server Name

Note: In all the following DNS configuration files, a line starting with a semicolon is a comment.

linuxconf

/etc/resolv.conf

/etc/named.boot

/var/named/named.mydomain.cxm

Hello World B: Recognize Virtual Domain Names

What We Will Build in the Hello World B DNS Exercise

Alias Domains

(Map to a Virtual Domain by a IN CNAME statement in /var/named/named.mydomain.cxm and enabled by a primary entry in /etc/named.boot.)

Virtual Domain

(Maps to the IP address by an IN A statement in /var/named/named.mydomain.cxm file.)

IP address

(Maps to the Home Directory by a <VirtualDomain> block in /etc/httpd/conf/httpd.conf), and enabled by an entry in linuxconf's config->
Networking->
server tasks->
IP aliases->
eth0

Home directory

(Maps to a web page by the content of this directory)

Web Page

troubleshooters.mydomain.cxm

Virtual Domains: General Principles

Hello World C: Add Reverse DNS Lookup

dnswalk: The Ultimate Test

Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist and of the Universal Troubleshooting Process courseware. He can be reached at Steve Litt's email address.

[ Back to this month's Troubleshooting Professional Magazine ]

[ Back to Troubleshooters.Com ]

Troubleshooters.Com presents

November 1998 Troubleshooting Professional Magazine

Hot off the Presses: Bind Version 8. WARNING!!!

Graduate Study: Setting Up DNS

By Steve Litt, Steve Litt's email address

Preparation

Absolute and relative names and numbers

Common mistakes:

When things really go wrong:

Start with a clean slate:

Hello World A: Recognize the Server Name

Note: In all the following DNS configuration files, a line starting with a semicolon is a comment.

linuxconf

/etc/resolv.conf

/etc/named.boot

/var/named/named.mydomain.cxm

Hello World B: Recognize Virtual Domain Names

What We Will Build in the Hello World B DNS Exercise

Alias Domains

(Map to a Virtual Domain by a IN CNAME statement in /var/named/named.mydomain.cxm and enabled by a primary entry in /etc/named.boot.)

Virtual Domain

(Maps to the IP address by an IN A statement in /var/named/named.mydomain.cxm file.)

IP address

(Maps to the Home Directory by a <VirtualDomain> block in /etc/httpd/conf/httpd.conf), and enabled by an entry in linuxconf's config-> Networking-> server tasks-> IP aliases-> eth0

Home directory

(Maps to a web page by the content of this directory)

Web Page

troubleshooters.mydomain.cxm

Virtual Domains: General Principles

Hello World C: Add Reverse DNS Lookup

dnswalk: The Ultimate Test

Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist and of the Universal Troubleshooting Process courseware. He can be reached at Steve Litt's email address.

[ Back to this month's Troubleshooting Professional Magazine ]

[ Back to Troubleshooters.Com ]

(Maps to the Home Directory by a <VirtualDomain> block in /etc/httpd/conf/httpd.conf), and enabled by an entry in linuxconf's config->
Networking->
server tasks->
IP aliases->
eth0