Did you come here from a search engine? Click here for my main page.

This page describes the network tools nslookup and host, which we use to find the IP addresses associated with named internet hosts. Either one or the other of these can be found on most modern computer operating systems (and are also available via the web), and they are very useful in the investigation of spam and other forms of internet abuse.

What they do

As you may know, every active internet site or host that has a name also has a numerical IP address. The linkage between the names and the addresses is set up and maintained in the domain name service (DNS), a worldwide distributed database that operates on the public network. Every time you send an e-mail, visit a website, or perform most any other internet task, you computer is making repeated queries to DNS in order to translate (or “resolve”) names into addresses. Normally, you neither see nor care about these lookups, but if you are going to track down spam or other forms of network abuse, you'll need to expose these addresses.

nslookup and host are basic network tools that can be used to "manually" query DNS to find the IP address corresponding to a host name or alias so that you can see the address for yourself. In some cases, these commands can also find the principal host name or alias that is associated with a particular IP address.

Finding the address associated with a host name is the first step in tracking down where the host (e.g., a spam website or mail host) is maintained, while being able to do "reverse" lookups (from address to name) can help you judge the bona fides of a mail host or other server.

Both nslookup and host really do the same thing and are very close to the same in operation; nslookup is the older of the two, and is gradually being replaced in most operating systems (like Apple Mac OS X / Darwin) by the host command. Don't throw out nslookup just yet, however: it can warn you that you're looking at cached information (which host does not do), so it remains useful for this reason.

How to get them

If you use a Unix-like system (such as Linux, BSD, Solaris, Apple Mac OS X / Darwin, etc.), you more than likely have nslookup available on your system already. If you have a newer distribution, or one that has been patched recently, you may also have host (and you may be gently nagged if you use nslookup instead). You need only run a terminal program (or otherwise get access to command-line operation) and then type the commands as shown below. Use the Unix whereis command (e.g., "whereis host") to find them if they aren't on your normal paths.

Most versions of Microsoft Windows (Win95 or later) should have nslookup available; you run it in a command window in pretty much the same manner described here for Unix systems.

If you are using some other operating system on your computer (in particular, Mac OS 9 and earlier), you may have neither nslookup nor host available to you. In this case, you can use one of the web-based alternatives described at the bottom of this page.

How to use them

On this page, we'll deal with the command-line versions of nslookup and host; web-based and GUI versions should also work in a similar fashion.

The basic command lines for these tools are:

Both nslookup and host have their own individual sets of options, some of the more useful of which will be described below.

"Forward" DNS lookup (get the IP address from the name)

The basic host command for an address lookup is pretty easy to use; you simply supply the host name you want to look up:

If your computer can reach a name server, host will return a result. For example:

[G4733:~] rconner% host www.rickconner.net
www.rickconner.net has address 209.198.131.19

Of course, not every host name will have an address on the public network. Here's a lookup for a name that doesn't (currently) have an IP address:

[G4733:~] rconner% host www.HurtMePlenty.com
Host www.HurtMePlenty.com not found: 3(NXDOMAIN)

Note here that host names in DNS are always case-insensitive (i.e., HurtMePlenty.com is the same as hurtmeplenty.COM or HURTMEPLENTY.Com), so it doesn't matter to DNS how you type them. Note also that "NXDOMAIN" is an error code returned by the name server indicating that the domain could not be found. This gives you the precise reason why the command failed. Another commonly-encountered error code is SERVFAIL, indicating that there was a name server failure somewhere along the line (the host name might still have an address, you just can't find it right now).

When using host, you should supply an actual host name (e.g., host99.somewhere.com) rather than a simple domain name (e.g., somewhere.com). If you supply host with a bare domain name, you may not get an answer. In practice, however, domain managers will usually set up their DNS so that a bare domain name lookup will return a "default" address (this allows you, for example, to type "google.com" in your browser to reach "www.google.com"). Many spammers also use such default DNS settings for their domain names, so host will probably be able to give you an answer for such names.

Some host names will actually resolve to more than one address. For example:

[G4733:~] rconner% host www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 64.233.161.99
www.l.google.com has address 64.233.161.104
www.l.google.com has address 64.233.161.147

This doesn't really mean that three different machines all have the host name "www.google.com"; what it means is that www.google.com is an alias that can point to any of the three machines listed here.

Each of these three addresses has the same name ("www.l.google.com") according to this lookup; this could be one gigantic machine with three Ethernet ports, three machines mapped to the same host name, or a larger number of machines connected to some router or gateway. We don't really know how Google does this, nor is it any of our business particularly. If we wanted to know the actual host names of these machines, we could (maybe) get them from a reverse lookup.

Authoritative vs. non-authoritative lookups: getting the straight dope

If you use nslookup rather than host, you will frequently see an address identified as a "non-authoritative answer." For example (here I used the -sil option with nslookup in Apple OS X Darwin to shut off its "deprecation nag"):

[G4733:~] rconner% nslookup -sil www.rickconner.net
Server: 199.45.32.43
Address: 199.45.32.43#53

Non-authoritative answer:
Name: www.rickconner.net
Address: 209.198.131.19

The "Non-authoritative answer" line (highlighted in blue) indicates that this IP address was retrieved from my local name server's cache, rather than from the "authoritative" name server for the rickconner.net domain.

What's a cache, you ask? A cache is simply where a name server stores name lookups for quick retrieval. Generally, each time a user makes a lookup, the local name server will put this result in its cache for a certain period of time. A cached lookup can be delivered much more quickly than one that requires a trip through the DNS hierarchy. Caching therefore improves the reliability and speed of name lookups. Since many internet transactions require numerous DNS lookups (e.g., a web page with many images linked via their own URLs), caching results in a dramatic improvement in perceived overall speed of service.

The problem with caching, however, is that the moment a name server caches a lookup, it loses contact with the "real-world" state of this lookup. If the name moves to a different address, or disappears from the network altogether, it will take all of the local name servers around the world some time (anywhere from a few minutes up to a day or two) to get updated with this fact. If you really want to know the status of a name lookup right now, then you need to do a bit of extra work to find the authoritative answer. You must:

  • Find out which hosts are acting as authoritative name servers for the domain of interest;
  • Do a host or nslookup query with one of these hosts directly to resolve the host name of interest.

To get an authoritative lookup for the host name (or alias) www.rickconner.net, we'll first use host with the -t NS option and the domain name rickconner.net ("-t NS" tells host to do a lookup of type NS — in other words, to print the authoritative name servers):

[G4733:~] rconner% host -t NS rickconner.net
rickconner.net name server ns1.prismnet.com.
rickconner.net name server ns2.prismnet.com.

Now, one more important tip: in order to have host look up the name using a specific name server (rather than the default name server associated with your internet service) you simply append the name of this "foreign" server to the end of the host command, like so:

Now, we'll redo the original host lookup, this time appending the name of one of these name servers (the one highlighted in blue) to tell host to get the info from this server:

[G4733:~] rconner% host www.rickconner.net ns1.prismnet.com
Using domain server:
Name: ns1.prismnet.com
Address: 209.198.128.11#53
Aliases:

www.rickconner.net has address 209.198.131.19

And there we are! It's comforting (to me at least) to learn that the two lookups gave the same IP address in response.

If you'd rather use nslookup to find the authoritative name servers, then use the form:

The MS-DOS/Windows syntax is also a bit different:

(Here's a Microsoft command reference for WinXP that may be of more help).

You can also get this info using the dig command, which will be easier to type but which will also produce a lot of output that may require some sifting to get at the answer.

In most cases, doing long-way-around authoritative name lookups for spam report research may be a bit anal-retentive, like wearing both suspenders and a belt. However, many spammers are now exploiting some fiddly bits in the DNS process to hide their domains or to make them appear at more than one location. They may have deliberately "stuffed the cache" of your local name server to direct you to the address they want, while at the same time they may have turned off authoritative name service for the domain (to make it harder for spam-tracers to find them). In these cases, it pays to be able to do both authoritative and non-authoritative lookups so that you can get a complete picture of the situation.

"Reverse" DNS lookup (get the name from the IP address)

Can you go backwards and get a host name from an address? You can certainly try. In this case, you type:

Will it work? Possibly, if so-called "reverse DNS" has been set up for the address. For example:

[G4733:~] rconner% host 209.198.131.19
19.131.198.209.in-addr.arpa domain name pointer www.rickconner.net.

What host has done here is to transform the address I entered into a special host-name-like format (19.131.198.209.in-addr.arpa) which it then looks up with my local name server. The name server tracks down this info, and finds that a "pointer record" has been set up (by my own hosting provider, in this case) identifying www.rickconner.net as the host name associated with this address.

When reverse DNS might not work ...

OK, now some apple-polishing smartass from the back of the room has asked what will happen if we look up the address for a particular host name, and then immediately look up the name associated with that address? We should get back the original name we entered, right? Not necessarily. For example, let's look at the host websphere.4hci.com:

Get the address from the name...
[G4733:~] rconner% host websphere.4hci.com
websphere.4hci.com has address 24.73.71.138

Get the name from the address...
[G4733:~] rconner% host 24.73.71.138
138.71.73.24.in-addr.arpa domain name pointer rrcs-24-73-71-138.se.biz.rr.com.

In this case, the address points back to a host name in the rr.com domain and not websphere.4hci.com as one might expect. Probably the operator of this host is simply using rr.com for his internet access, and rr.com didn't set up reverse DNS to point back to this same host name. There's nothing funny going on here; both names point to the same address, and therefore to the same machine, it's just that the reverse DNS wasn't set up in the way you might expect.

Which brings us to an important observation about reverse DNS: there's no need to set it up if it isn't strictly necessary. Satisfying the curiosity of freelance network geeks like me does not fall into the category of "strictly necessary."

When reverse DNS had better work ...

One type of machine that does require good reverse DNS, however, is the SMTP mail host. As you can learn from reading my page on an e-mail transaction, a mail host that wants to drop off a message for another mail host will identify itself by name by sending a HELO message to the receiving host. The receiving host will (usually) record both this name and the IP address of the sender in the Received: line it adds to the header of the message. One common application of reverse DNS is to help do a "both-ways" check of the HELO name and its supposed IP address.

Suppose we received an e-mail with the following Received: line (actually, as it happens, I did receive such a message):

Received: from netscape.net ([200.168.1.15]) by mta001.verizon.net

This header line asserts that netscape.net has the IP address 200.68.1.15. Does it? We can check:

Check the name ...
[G4733:~] rconner% host netscape.net
netscape.net has address 205.188.142.182
netscape.net has address 64.12.50.151

Reverse-DNS to check the address ...
[G4733:~] rconner% host 200.168.1.15
15.1.168.200.in-addr.arpa domain name pointer 200-168-1-15.speedyterra.com.br.

So, the address doesn't point to the name, and the name doesn't point to the address. This is pretty clear evidence of header forgery, and you won't have much trouble proving this to the owner of 200.168.1.15. (unless, of course, he doesn't want to hear about it — but that's a topic for another time).

Now here's an example (which I phonied up myself) that shows an honest mail host, but one with misconfigured reverse DNS:

Received: from mta3.wonton.info ([12.34.56.78]) by mta001.verizon.net

Let's do the both-ways check on this guy:

Check the name ...
[G4733:~] rconner% host mta3.wonton.info
mta3.wonton.info has address 12.34.56.78

Reverse-DNS to check the address ...
[G4733:~] rconner% host 12.34.56.78
78.56.34.12.in-addr.arpa domain name pointer owl.bassinet.com.

So, the "forward DNS" works fine (which should mostly convince us that the mail did indeed originate from the wonton.info domain), but the reverse DNS doesn't point us back to mta3.wonton.info. More than likely, the folks at wonton.info simply set up a DNS alias of "mta3.wonton.info" for the box actually named owl.bassinet.com, but did not go all the way and set up a pointer record. This is a bit more ambiguity than we like to see among mail hosts; it would be better if the wonton.info people set up the proper pointer record, or else used "owl.bassinet.com" as their HELO name.

Alternatives to command-line nslookup and host

If you don't have nslookup or host available on your system, or don't want to use command lines, you still have several alternatives. The following links may be helpful:

You may also search your favorite free-software repository to find "GUI" software for your system that will do DNS lookups.



 Legend:  new window    outside link    tools page  glossary link   


(c) 2003-2008, Richard C. Conner ( )

37729 hits since March 27 2009

Updated: Fri, 04 Jul 2008