HOST, DIG, AND NSLOOKUP | Anti-Hacker Tool Kit, Third Edition

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.

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:

 [Paris:~] mike% nslookup -silent www.antihackertoolkit.com Server:         10.0.1.1 Address:        10.0.1.1#53 Non-authoritative answer: www.antihackertoolkit.com       canonical name = antihackertoolkit.com. Name:   antihackertoolkit.com Address: 66.92.146.207 [Paris:~] mike% host www.antihackertoolkit.com www.antihackertoolkit.com has address 66.92.146.207

As you can see, both commands told us the IP address of http://www.antihackertoolkit.com.

 [Paris:~] mike% host antihackertoolkit.com antihackertoolkit.com has address 69.250.207.79

Here we've discovered that antihackertoolkit.com resolves to the same IP address as http://www.antihackertoolkit.com (which isn't surprising). 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, antihackertoolkit.com's SOA states that DNS information from its DNS server should only be considered valid for 86400 seconds (24 hours) by specifying a minimum time-to-live (TTL). After 24 hours, DNS servers should stop using any cached information about the domain and check the primary DNS server to see if that information has changed. A breakdown of the SOA fields is provided in Table 14-1.

 [Paris:~] mike% host -t mx antihackertoolkit.com antihackertoolkit.com mail is handled by 0 mail.aidenjones.com. [Paris:~] mike% host -t soa antihackertoolkit.com antihackertoolkit.com SOA dns21.register.com. root.register.com.  200205343 10800 3600 604800 86400

Table 14-1: DNS Start of Authority Field Descriptions
SOA Field	Description	Example Value
serial (version)	The current version of the DNS database that contains information about this domain.	200205343
refresh period	Time in seconds for secondary name servers to check for changes on the primary server.	10800
retry refresh this often	If a secondary server fails to connect to its primary server, retry the connection after this number of seconds.	3600
expiration period	Number of seconds after which a stale record (a record which cannot be refreshed from the primary server) should be removed from the secondary server.	604800
minimum TTL	Check for refreshes on this particular domain after this number of seconds.	86400

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 secondary 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 against a different domain: wedgie.org. Most DNS and network administrators have begun to explicitly block zone transfers. So, here's an example of one that isn't blocked:

 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

Note	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 http://www.yahoo.com http://www.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

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 server, 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).