Host, Dig, and Nslookup | Anti-Hacker Tool Kit, Third Edition

< Day Day Up >

Three other tools that usually come installed by default on Unix systems are host, dig, and nslookup. These utilities are part of a package called BIND (which stands for Berkeley Internet Name Domain), the most popular Unix name server (available from http://www.isc.org/products/BIND/). These tools can be used to query Domain Name Service (DNS) servers about what they know. Primarily, DNS servers map hostnames to IP addresses and vice versa. However, DNS servers can also tell you other information as well, such as which host is the registered mail handler for a specified domain.

Note

Nslookup is available on most Windows platforms starting with Windows 2000. Many commercial and shareware Windows products include host and dig tools, such as NetScanTools in Chapter 4.

Implementation

The host and nslookup tools are quite similar. They do basically the same thing except that nslookup provides an optional interactive interface whereas host is strictly command-line based. Due to their similarities, nslookup may be dropped in future releases of the BIND utilities. For this reason, we’ll focus primarily on the host tool. Default usage of nslookup and host look like this:

bash-2.03$ nslookup got.wedgie.org Server:  localhost.wedgie.org Address:  127.0.0.1     Name:    got.wedgie.org Address:  66.92.146.207     bash-2.03$ host got.wedgie.org got.wedgie.org has address 66.92.146.207 bash-2.03$

As you can see, both commands told us the IP address of got.wedgie.org. What if we wanted information on the entire wedgie.org domain?

bash-2.03$ host wedgie.org wedgie.org has address 66.92.146.207 wedgie.org mail is handled (pri=10) by got.wedgie.org bash-2.03$

Here we’ve discovered that wedgie.org resolves to the same IP address as got.wedgie .org. We also know that got.wedgie.org is the primary mail handler or mail transfer agent for the wedgie.org domain. The host utility can be used to obtain other types of information using the –t <querytype> command-line option. Standard queries are for hostname to address mappings (a), name server specifications (ns), mail handler specifications (mx), address to hostname mappings (ptr), and start of authority entries (soa). Because most DNS servers will cache data to reduce the amount of lookups and queries they have to send to other authoritative servers, the SOA record can be used to specify how long a DNS entry from that server should stay in cache before it expires. For example, wedgie.org’s SOA states that DNS information from its DNS server should only be considered valid for 3600 seconds (1 hour) by specifying a minimum time-to-live (TTL). After an hour, DNS servers should stop using any cached information about wedgie.org and check with wedgie.org’s DNS server to see if that information has changed.

bash-2.03$ host -t soa wedgie.org wedgie.org start of authority   wedgie.org nobody.wedgie.org(                         2003022006      ;serial (version)                         3600    ;refresh period                         300     ;retry refresh this often                         3600000 ;expiration period                         3600    ;minimum TTL                         ) bash-2.03$

If you want to try all types of queries against a DNS server, use the –a flag.

Much of the SOA record deals with how often slave DNS servers should check with master DNS servers for updated records. The process of slave servers updating their records from the master server is called a zone transfer. Most DNS servers won’t allow just anyone to perform a zone transfer, as it provides you with hostname/IP mappings for every host in the domain. Administrators should configure their DNS servers so that only slaves can perform zone transfers. The reality, however, is that this is sometimes overlooked. Here, we’ll run an example zone transfer of wedgie.org on wedgie.org’s name server (it allows a zone transfer to itself) using the host –l command.

bash-2.03$ host -l wedgie.org wedgie.org name server got.wedgie.org wedgie.org has address 66.92.146.207 tele.wedgie.org has address 207.196.92.133 fear-bob-the-dinosaur-giving-you-a.wedgie.org has address 129.2.176.36 frozen.otters.give.good.wedgie.org has address 216.62.54.241 painful.wedgie.org has address 216.181.169.149 mini.wedgie.org has address 216.181.169.148 got.wedgie.org has address 66.92.146.207 bash-2.03$

Tip

When you don’t specify a query type, it defaults to a records. If you want to see all records associated with a domain when attempting a zone transfer, try host –t any –l domainname.com.

Although this example zone transfer is mainly humorous and not terribly informative, you can see how a domain’s host and IP list could be very useful to a potential attacker. A zone transfer is a quick and easy discovery method for network information.

The host command uses your default name server by default when performing its queries. If you want to query a different name server, simply specify its hostname or IP address at the end of the command line, such as host –l yahoo.com dns.yahoo.com.

The dig tool is also similar to host and nslookup, but it gives you more raw input and output than the user-friendlier host and nslookup. With dig, you first specify the DNS server you’re querying (preceded by an @ sign), the host or domain you’re querying about, and then the type of query. The query types are the same as those for host, and you can read more about them in RFC 1035 (http://www.faqs.org/rfcs/rfc1035.html). Here’s what a zone transfer looks like with dig:

bash-2.03$ dig @got.wedgie.org wedgie.org axfr     ; <<>> DiG 8.3 <<>> @got.wedgie.org wedgie.org axfr ; (1 server found) $ORIGIN wedgie.org. @                       1H IN SOA       @ nobody.wedgie.org. (                                         2003022006      ; serial                                         1H              ; refresh                                         5M              ; retry                                         5w6d16h         ; expiry                                         1H )            ; minimum                             1H IN NS        got                         1H IN A         66.92.146.207                         1H IN MX        10 got bill.gates.needs.a      1H IN CNAME     www.microsoft.com. tele                    1H IN A         207.196.92.133 fear-bob-the-dinosaur-giving-you-a  1H IN A  129.2.176.36 crashbox                1H IN A         216.181.169.152 ...

Another neat trick you can do with these BIND utilities is discovering the version number that a BIND name server is running. If you query a BIND server for version.bind. with a query type of txt and a query class of chaos, the BIND server will reveal its version number.

bash-2.03$ dig @got.wedgie.org version.bind. txt chaos     ; <<>> DiG 8.3 <<>> @got.wedgie.org version.bind. txt chaos ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;;      version.bind, type = TXT, class = CHAOS     ;; ANSWER SECTION: VERSION.BIND.           0S CHAOS TXT    "8.3.4-REL"     ;; Total query time: 1 msec ;; FROM: got.wedgie.org to SERVER: got.wedgie.org  66.92.146.207 ;; WHEN: Sun Sep  7 18:44:07 2003 ;; MSG SIZE  sent: 30  rcvd: 64     bash-2.03$

Tip

You can prevent your BIND DNS server from providing this information by specifying an option in your named.conf file like this: options { version "None"; };.

As mentioned earlier, DNS servers should be configured to allow zone transfers only to “trusted” networks. This can be done using the allow-transfer directive in BIND’s named.conf file. To a well-configured DNS servers, these BIND utilities aren’t quite as powerful. However, for a poorly configured DNS server, these tools can provide a hacker not only with a hostname-IP map of presumably every host on the network, but also identification of a potentially vulnerable service (if your version of BIND happens to be vulnerable to an exploit).

< Day Day Up >