Basic DNS Tools

FreeBSD includes several tools for inspecting DNS information. Since most DNS runs over the User Datagram Protocol (UDP), you cannot use telnet to manually query a server as we will do with email and Web services later. Your only access to live DNS information is through host(1) and dig(1).

The Host Command

To quickly check the IP address of a host, use the host(1) command. For example, to check my publisher's Web page, I would do the following:

...............................................................................................

# host www.nostarch.com

www.nostarch.com is a nickname for nostarch.com nostarch.com has address 66.80.60.21

nostarch.com mail is handled (pri=20) bysmtp.lax.megapath.net nostarch.com mail is handled (pri=10) by mail.nostarch.com

#

...............................................................................................

This is somewhat interesting because it shows us that under DNS, one host can have multiple names and multiple Web pages on one IP address. This output tells us that the main No Starch Press Web page is actually a nickname for another hostname, http://nostarch.com/; one IP address can have any number of names. This is much like the phone system in a typical family household, in which several people share one telephone. The people are like hostnames, while the phone number is like an IP address. The host does have a single, canonical name, much as a phone is registered to a single person.

Note Many server programs require much more than an IP address to function. For example, if you enter http://66.80.60.21/ in your Web browser, you'll actually pull up the page for No Starch Press's hosting provider, not the page for No Starch Press. We'll look at how popular Web servers multiplex multiple Web sites onto a single IP address in Chapter 15, but it's something you should keep in the back of your mind for future reference.

Getting Detailed Information with Dig

While the host command is quite helpful, it's certainly not detailed. Also, you don't know where this information came from—whether it was taken straight from the cache or whether the nameserver dug it up from the domain's nameserver. The standard program for finding detailed DNS information is dig(1). (Another tool, nslookup(1), was popular for many years but has since fallen out of favor.) Dig has a variety of options that allow you to debug a wide range of nameservice problems, though I'll cover only the most basic ones here.

In its most basic form, a dig command is simply dig and a hostname. For example, to dig up information on my publisher, I would enter this command:

...............................................................................................

dig www.nostarch.com

v ; <<>> DiG 8.3 <<>>; www.nostarch.com

w ;; res options: init recurs defnam dnsrch x ;; got answer:

269

;;−>>HEADER<<− opcode: QUERY, status: y NOERROR, id: 4

;;flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 z ;; QUERY SECTION:

;;www.nostarch.com, type = A, class = IN { ;; ANSWER SECTION:

www.nostarch.com. 2h13m2s IN CNAME nostarch.com. nostarch.com. 2h13m2s IN A 66.80.60.21

| ;; AUTHORITY SECTION:

nostarch.com. 7h48m45s IN NS NS1.MEGAPATH.NET. nostarch.com. 7h48m45s IN NS NS2.MEGAPATH.NET. } ;; ADDITIONAL SECTION:

NS1.MEGAPATH.NET. 7h48m35s IN A 216.200.176.4 NS2.MEGAPATH.NET. 7h48m35s IN A 216.34.237.2

;;Total query time: 11 msec

;;FROM: blackhelicopters.org to SERVER: default −− 127.0.0.1

;;WHEN: Sun Apr 7 12:24:17 2002

;;MSG SIZE sent: 34 rcvd: 144

...............................................................................................

Wow, talk about a lot of information! (When you're using dig, you're probably trying to debug something. It's better to have too much information than not enough.)

So what have we learned? To start with, anything beginning with semicolons is a comment that either lists the options used by dig or divides the answers into sections.

The first line (v) lists the version of dig you're using, and the command−line options you used. The second line (w) lists the options that dig is using. (Since we didn't specify any options on the command line, these are the default options; we'll discuss some useful options later.)

The third line (x) tells us whether dig got an answer (it did). The next line (y) contains an important word, NOERROR, which tells us that dig found an answer that appears to be good. If you don't get a NOERROR, you have a problem. (Common errors are NXDOMAIN, meaning that the domain doesn't exist, or SERVFAIL, meaning that the domain is misconfigured on that server.)

The next couple of lines contain codes that really aren't of use unless you're heavily into debugging DNS or doing some weird things. So let's jump to the four sections that follow: the query, answer, authority, and additional sections.

The Query Section

In the query section (z), we see how dig is treating the query. In our sample we see the following:

...............................................................................................

;; www.nostarch.com, type = A, class = IN

...............................................................................................

Let's start with the easy bit, the class. While DNS can manage many different naming systems, the one we're concerned with is the Internet system, or IN. Internet domains should always have the class IN.

270

The type is the type of record we're looking for. By default, dig looks for an A (address) record, which means that we have the name, but want the IP address. A PTR (pointer) record request means that we have an IP address and want the associated name.

The Answer Section

Next we have the answer section ({). The first thing it contains is the host we're looking for (http://nostarch.com/). The next figure (2h13m2s IN CNAME) is the time to live for this information—the amount of time your local nameserver may cache it. The 2h13m2s indicates that this data expires in 2 hours, 13 minutes, and 2 seconds. The IN, again, indicates that this is Internet data. Finally, CNAME means that what follows is a canonical name for the server, which tells us that what we're looking for is actually an alias for something else. The dig output confirms that http://www.nostarch.com/ is actually an alias for http://nostarch.com/.

The second line of the answer section is almost identical to the first, except it has an A instead of a CNAME. This tells us that what follows is an IP address.

The Authority Section

To get the IP address of http://www.nostarch.com/, we have to follow the chain of authoritative nameservers. The authority section (|) lists the servers responsible for the domain, their time to live, and the sort of data and servers that they are. In this case, the nameservers are ns1.megapath.net and ns2.megapath.net. Data for http://www.nostarch.com/ is to be cached for 7 hours, 48 minutes, and 45 seconds, and these are (again) Internet (IN) records. The NS means that these are nameservers.

The Additional Section

Finally, under the additional section (}), dig lists the IP addresses of all the hosts listed with the host we want. Our example lists the nameservers for http://www.nostarch.com/: ns1.megapath.net and ns2.megapath.net. The interesting thing here is that the time to live is 7 hours, 48 minutes, and 35 seconds. In this case, the time to live isn't the value for how long the local nameserver should keep the information on the hosts, it's how long the data on the nameservers for http://nostarch.com/ should be kept. Once this time passes, your nameserver will discard the information and go fetch the nameserver list from one of the Internet's root nameservers. This isn't necessarily good or bad, but if you're trying to solve a problem, it's good to know.

Do a dig on a couple of domains and become familiar with how the output should look.

Looking Up Hostnames with Dig

Suppose you have an IP address and want to identify the associated hostname; for example, you might want to learn who owns a phone number. This is a common problem on the Internet—you might see an IP address hitting your Web site every five seconds, and wonder who they are and what they're trying to do.

To look up the name, use reverse lookup with dig's −x option. Since much of the result is completely identical to what you see in the forward lookup, we'll only look at the section that's different: the answer.

...............................................................................................

# dig −x 66.80.60.21

;; ANSWER SECTION:

271

21.60.80.66.in−addr.arpa. 2h24m IN PTR www.megapathdsl.net....

#

...............................................................................................

Although we know that at least http://www.nostarch.com/ and http://nostarch.com/ live on this IP address, this reverse lookup shows us the most correct name for the host. Both of those machine names live on a machine that is actually called http://www.megapathdsl.net/.

The PTR entry in the middle of the answer indicates that this is a pointer record. It is a specific sort of entry used to mark IP−address−to−hostname records. When you set up DNS, every host with an IP address will need both a PTR and an A record in your nameservice system.

More Dig Options

The dig program takes a wide variety of command−line options to control how it checks for information. Check dig(1) for a complete list of these options. We'll only discuss the servername and norecurse options here, because they're the ones most commonly used.

Server Name

The first option is the server name. By default, dig queries the first nameserver listed in /etc/resolv.conf. If you're trying to debug a problem, however, you want to ask different nameservers. You can do this on the command line by using the @ option. For example, to ask http://dns1.yahoo.com/ what it knows about http://absolutebsd.com/ enter this:

...............................................................................................

# dig @dns1.yahoo.com AbsoluteBSD.com

...............................................................................................

The output from this command will look much like the sample output shown earlier, except that you'll see references to Yahoo!'s nameserver. If you're debugging a problem, you should compare this information carefully with that given by your local nameserver. If information from two different nameservers conflicts, you may well have found your problem. (DNS information should only change when you add hosts, rename hosts, or renumber hosts.) You can use some of dig's other options to see exactly where the problem occurs.

Controlling How Dig Queries

Dig has two other sorts of options: those that control how dig itself runs, and those that control how dig makes queries. The options that control how dig runs are prefaced with a minus sign ( ); those that control how dig makes its queries are prefaced by a plus sign (+). While dig can do a lot of really nifty tricks, they're beyond the scope of this chapter. Controlling how it makes the queries is quite useful, however.

By default, a nameserver will recurse queries to return an answer. While this is helpful if you're asking the nameserver about a domain, you don't want the nameserver to dig up the answer for you when you're debugging; instead, you want to check each nameserver in turn. You can do this with the norecurse option.

272