3.3 DNS Querying

Using tools such as nslookup, host, and dig, you can launch DNS requests and probes against domains and IP address blocks identified during the web search and NIC querying phases. Other tools also perform reverse DNS sweeps against IP network blocks to identify hostnames and other domains.

DNS requests and probes can be launched to retrieve parts of, or in some cases, entire DNS zone files for specified domains or network spaces. Most DNS servers around the Internet can be quizzed for useful information, including:

  • Authoritative DNS server information from name server (NS) records

  • Domain and subdomain information

  • Hostname information from A, PTR, and CNAME records

  • Public points of presence that list mail exchanger (MX) records

In some cases, poorly configured DNS servers also allow you to enumerate:

  • Operating-system and platform information of hosts from the host information (HINFO) record

  • Names and IP addresses of internal or nonpublic hosts and networks

You can very often uncover previously unknown network blocks and hosts during DNS querying. If new network blocks are found, I recommend launching a second round of WHOIS queries and web searches to get further information about each new network block.

DNS probing in this fashion is stealthy in the sense that there is no active scanning or probing of the target networks. Instead, you simply probe and query the authoritative DNS servers for those domains or network blocks that are often run by ISPs. Most name servers aren't even configured to pick up on potential sweeps of this sort, because it resembles standard DNS traffic.

3.3.1 Forward DNS Querying

Forward DNS records are required for organizations and companies to integrate and work correctly as part of the Internet. Two examples of legitimate forward queries are when an end user accesses a web site and during the receipt of email when SMTP mail exchanger information is requested about the relevant domain. Attackers issue forward DNS queries to identify mail servers and other obvious Internet-based systems.

Tools that query DNS servers directly include:

  • The Sam Spade Windows client (available from http://www.samspade.org)

  • The nslookup client found within most operating systems

  • The host client found within Unix environments

  • The dig client found within Unix environments Forward DNS querying through nslookup

Using the nslookup tool in an interactive fashion (from either a Windows or Unix-based command prompt) I can identify the mail exchanger IP addresses and hostnames for the Central Intelligence Agency (CIA) domain at cia.gov, as shown in Example 3-3. Note that ucia.gov is used as the real domain name for the CIA's network space.

Example 3-3. Using nslookup to enumerate basic domain details
# nslookup

Default Server:  onyx


> set querytype=any

> cia.gov

Server:  onyx


Non-authoritative answer:


        origin = ucia.gov

        mail addr = root.ucia.gov

        serial = 21432040

        refresh = 900 (15M)

        retry   = 3600 (1H)

        expire  = 86400 (1D)

        minimum ttl = 900 (15M)

cia.gov nameserver = relay1.ucia.gov

cia.gov nameserver = auth00.ns.uu.net

cia.gov preference = 5, mail exchanger = relay2.ucia.gov

Authoritative answers can be found from:

cia.gov nameserver = relay1.ucia.gov

cia.gov nameserver = auth00.ns.uu.net

relay1.ucia.gov internet address =

auth00.ns.uu.net        internet address =

relay2.ucia.gov internet address =

Mail exchanger (MX) address details are very useful to attackers because such mail servers often reside on the corporate network boundary between the Internet and internal network space. By scanning these systems, attackers can often identify other gateways and systems that aren't secure. Forward DNS querying through host

The Unix host command can easily identify the mail exchanger for the cia.gov domain:

# host cia.gov

cia.gov mail is handled (pri=5) by relay2.ucia.gov

Other arguments can be provided to the host command to pull specific DNS information (type man host to access its manpage). Forward DNS querying through dig

The Unix-based dig command is extremely powerful with plenty of options and functionality. Example 3-4 shows the basic accessible DNS information for the cia.gov domain.

Example 3-4. Using dig to enumerate basic domain details
# dig cia.gov any

; <<>> DiG 8.3 <<>> cia.gov any

;; res options: init recurs defnam dnsrch

;; got answer:

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

;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 3


;;      cia.gov, type = ANY, class = IN


cia.gov.                13m47s IN SOA   ucia.gov. root.ucia.gov. (

                                        21432040        ; serial

                                        15M             ; refresh

                                        1H              ; retry

                                        1D              ; expiry

                                        15M )           ; minimum

cia.gov.                13m47s IN NS    relay1.ucia.gov.

cia.gov.                13m47s IN NS    auth00.ns.uu.net.

cia.gov.                13m47s IN MX    5 relay2.ucia.gov.


cia.gov.                13m47s IN NS    relay1.ucia.gov.

cia.gov.                13m47s IN NS    auth00.ns.uu.net.


relay1.ucia.gov.        23h58m47s IN A

auth00.ns.uu.net.       8h31m27s IN A

relay2.ucia.gov.        13m48s IN A

;; Total query time: 10 msec

;; MSG SIZE  sent: 25  rcvd: 221

In the overall scheme of things, dig has superseded the nslookup and host commands, allowing users to launch and analyze responses to almost raw DNS queries. Information retrieved through forward DNS querying

The initial forward DNS queries against cia.gov identify the authoritative DNS servers as relay1.ucia.gov and auth100.ns.uu.net, and the mail exchanger for the domain as relay2.ucia.gov. The IP address details of these hosts can then be queried using the WHOIS web interface at ARIN, which reveals that the CIA has reserved the IP address network block.

3.3.2 DNS Zone Transfer Techniques

Perhaps the most popular method for gathering information about all the computers within a DNS domain is to request a zone transfer. A DNS zone file contains all the naming information that the name server stores regarding a specific DNS domain, often including details of nonpublic internal networks and other useful information you can use to build an accurate map of the target infrastructure.

Most organizations, for load balancing and fault tolerance reasons, use more than one name server. The main name server is known as the primary name server and all subsequent name servers are secondary name servers. Either a primary or secondary name server can be queried for name resolution, so it is important that each name server have current DNS zone information. To ensure this is the case, when a secondary name server is started and at regular, specifiable intervals thereafter, it requests a complete listing of the computers it is responsible for from the primary name server. The process of requesting and receiving this information is a zone transfer.

Tools used to request DNS zone transfer information include:

  • The Sam Spade Windows client (available from http://www.samspade.org)

  • The nslookup client found within most operating systems

  • The host client found within Unix-based environments

  • The dig client found within Unix-based environments Performing DNS zone transfers with nslookup

When used in an interactive fashion, the nslookup command can perform a DNS zone transfer against a given domain by connecting to an authoritative name server. In some cases, nonauthoritative name servers can be queried in this fashion, so they are always worth looking for. Example 3-5 shows how nslookup can be run to identify the authoritative name servers for the ucia.gov domain.

Example 3-5. Using nslookup to glean authoritative DNS server details
# nslookup

Default Server:  onyx


> set querytype=any

> ucia.gov

Server:  onyx


Non-authoritative answer:

ucia.gov        preference = 10, mail exchanger = puff.ucia.gov

ucia.gov        preference = 5, mail exchanger = relay2.ucia.gov


        origin = ucia.gov

        mail addr = root.ucia.gov

        serial = 21642034

        refresh = 900 (15M)

        retry   = 3600 (1H)

        expire  = 86400 (1D)

        minimum ttl = 900 (15M)

Authoritative answers can be found from:

ucia.gov        nameserver = RELAY1.ucia.gov

ucia.gov        nameserver = AUTH100.NS.UU.NET

puff.ucia.gov   internet address =

relay2.ucia.gov internet address =

RELAY1.ucia.gov internet address =

AUTH100.NS.UU.NET       internet address =

Initial DNS records (details of mail servers for the domain and other information) and addresses of authoritative DNS servers are supplied. Example 3-6 walks through the zone transfer process against the CIA, connecting directly to auth100.ns.uu.net and issuing the ls -d ucia.gov command.

Example 3-6. Interactively using nslookup to perform a zone transfer
> server auth100.ns.uu.net

Default Server:  auth100.ns.uu.net


> ls -d ucia.gov


$ORIGIN ucia.gov.

@                       15M IN SOA      @ root (

                                        21642034        ; serial

                                        15M             ; refresh

                                        1H              ; retry

                                        1D              ; expiry

                                        15M )           ; minimum

                        15M IN NS       relay1

                        15M IN NS       auth00.ns.uu.net.

                        15M IN NS       puff

                        15M IN NS       magic.cia.gov.

                        15M IN MX       10 puff

                        15M IN MX       5 relay2

ain-relay1              15M IN CNAME    relay1

loghost                 15M IN CNAME    localhost

ain-relay2              15M IN CNAME    relay2

localhost               15M IN A

*                       15M IN MX       10 puff

ain-relay1-ext          15M IN CNAME    relay1

iron                    15M IN NS       relay1

                        15M IN NS       auth00.ns.uu.net.

relay4-ext              15M IN CNAME    relay4

relay4-hme0             15M IN CNAME    relay4

ex-rtr-191-a            15M IN A

ex-rtr-191-b            15M IN A

relay                   15M IN CNAME    relay1

relay2-int              15M IN CNAME    ain-relay2-le1

relay2-hme0             15M IN CNAME    relay2

relay1-hme0             15M IN CNAME    relay1

multicast               15M IN A

foia                    15M IN NS       relay1

                        15M IN NS       auth00.ns.uu.net.

amino                   15M IN NS       relay1

                        15M IN NS       auth00.ns.uu.net.

ain-relay2-ext          15M IN CNAME    relay2

relay1-ext              15M IN CNAME    relay1

ain-relay4-int          15M IN CNAME    ain-relay4-hme1

net                     15M IN NS       relay1

                        15M IN NS       auth00.ns.uu.net.

tonic                   15M IN NS       relay1

                        15M IN NS       auth00.ns.uu.net.

ex-rtr                  15M IN CNAME    ex-rtr-129

bh-ext-hub              15M IN A

wais                    15M IN CNAME    relay2

lemur                   15M IN NS       relay1

                        15M IN NS       auth00.ns.uu.net.

ain-relay4-hme0         15M IN CNAME    relay4

relay2-ext              15M IN CNAME    relay2

ain-relay4-hme1         15M IN A

ain-relay2-hme0         15M IN CNAME    relay2

ain-relay1-int          15M IN CNAME    ain-relay1-le1

ain-relay2-hme1         15M IN A

ain-relay1-hme0         15M IN CNAME    relay1

ain-relay1-hme1         15M IN A

relay4-int              15M IN CNAME    ain-relay4-hme1

relay1                  15M IN A

relay2                  15M IN A

relay4                  15M IN A

iodine                  15M IN NS       relay1

                        15M IN NS       auth00.ns.uu.net.

ain-relay-int           15M IN CNAME    ain-relay1-le1

relay-int               15M IN CNAME    ain-relay1-le1

puff                    15M IN A

ain-relay4-ext          15M IN CNAME    relay4

ex-rtr-129              15M IN HINFO    "Cisco 4000 Router"

                        15M IN A

loopback                15M IN CNAME    localhost

ain-relay2-int          15M IN CNAME    ain-relay2-le1

relay1-int              15M IN CNAME    ain-relay1-le1 Information retrieved through DNS zone transfer

Interesting security-related information that can be derived from the CIA's large DNS zone file includes:

  • The CIA relay mail and DNS servers are probably running Solaris, due to the naming convention of using hme within the hostnames (hme devices are network interfaces within Solaris).

  • iron.ucia.gov, foia.ucia.gov, amino.ucia.gov, net.ucia.gov, tonic.ucia.gov, and lemur.ucia.gov are all valid subdomains of ucia.gov.

  • The ain-relay servers seem to be dual-homed, also existing internally at and

  • An HINFO record exists for ex-rtr-129, telling us it is a Cisco 4000 series router.

  • The following CIA IP address blocks are identified:

  • (Internet-based)

  • (Internet-based)

  • (nonpublic reserved IANA address space)

  • (nonpublic reserved IANA address space) Performing DNS zone transfers using host and dig

The Unix host utility can be run in a noninteractive fashion from the command line to retrieve the same DNS zone file information by using the following flags:

# host -l -t any ucia.gov

dig is another tool used to retrieve DNS zone information; it's run with the following options to perform a DNS zone transfer of ucia.gov from auth100.ns.uu.net:

# dig @auth100.ns.uu.net ucia.gov axfr Further querying

After performing a DNS zone transfer, subdomains are identified. Using the host command (available under most Unix-based systems), you can transfer DNS zone information from authoritative name servers without using nslookup in an interactive fashion. Mapping subdomains with host

Example 3-7 uses the host command to enumerate address (A) records for the CIA's net.ucia.gov subdomain.

Example 3-7. Using host to identify addresses under net.ucia.gov
# host -l -t a net.ucia.gov

net.ucia.gov name server auth100.ns.uu.net

auth100.ns.uu.net has address

net.ucia.gov name server relay1.ucia.gov

relay1.ucia.gov has address

dialbox0.net.ucia.gov has address

By recursively querying the CIA's authoritative name servers, it is possible to identify a number of Internet-based points of presence, including an apparent dial-up server (dialbox0.net.ucia.gov) on a previously unknown IP range of In this particular case, I use the -t a argument, which displays all known address and name server records, but not host information (HINFO) records. To list all records, simply use the -t any argument. Example of a DNS zone transfer refusal

It is often the case that large organizations, such as the CIA, return copious amounts of DNS zone information (including the names of subdomains, key servers, and development hosts). Companies that are aware of DNS security issues don't allow DNS zone transfers; for example:

# host -l ibm.com

Server failed: Query refused

3.3.3 Reverse DNS Sweeping

After building a list of IP network blocks used or reserved by the target organization, reverse DNS sweeping can gather details of hosts that may be protected or filtered but still have DNS hostnames assigned to them.

ghba is a freely available tool that performs reverse DNS sweeping of target IP network space. You can find it at http://www.attrition.org/tools/other/ghba.c.

Example 3-8 shows the ghba utility being downloaded, built, and run against a CIA network block to identify hosts.

Example 3-8. Using ghba to perform a reverse DNS sweep
# wget http://www.attrition.org/tools/other/ghba.c

# ls


# cc -o ghba ghba.c

ghba.c: In function 'main':

ghba.c:105: warning: return type of 'main' is not 'int'

# ls

ghba ghba.c

# ./ghba

usage: ghba [-x] [-a] [-f <outfile>] aaa.bbb.[ccc||0].[ddd||0]

# ./ghba

Scanning Class C network 198.81.129... => www.odci.gov => www2.cia.gov => ain-relay4-hme1.ucia.gov => relay1.ucia.gov => relay2.ucia.gov => relay4.ucia.gov => ex-rtr-129.ucia.gov => res.odci.gov

As well as identifying already known CIA web and mail relay servers, ghba identifies various other hosts, including res.odci.gov and www.odci.gov. Reverse DNS sweeping is a useful technique that can identify hosts and potential weaknesses within Internet-based points of presence because it reveals hosts and networks that may not be revealed during DNS zone transfer queries.

3.3.4 SMTP Probing

SMTP gateways and networks of mail relay servers must exist for organizations and companies to send and receive Internet email messages. Simply sending an email message to an address known not to exist at a target domain, often reveals useful internal network information. Example 3-9 shows how email sent to a user account that doesn't exist within the ucia.gov domain bounces to reveal useful internal network information.

Example 3-9. A nondeliverable mail transcript from the CIA
The original message was received at Fri, 1 Mar 2002 07:42:48 -0500

from ain-relay2.net.ucia.gov []

   ----- The following addresses had permanent fatal errors -----


   ----- Transcript of session follows -----

... while talking to mailhub.ucia.gov:

>>> RCPT To:<blahblah@ucia.gov>

<<< 550 5.1.1 <blahblah@ucia.gov>... User unknown

550 <blahblah@ucia.gov>... User unknown

   ----- Original message follows -----

Return-Path: <hacker@hotmail.com>

Received: from relay2.net.ucia.gov

        by puff.ucia.gov (8.8.8+Sun/ucia internal v1.35)

        with SMTP id HAA29202; Fri, 1 Mar 2002 07:42:48 -0500 (EST)

Received: by relay2.net.ucia.gov; Fri, 1 Mar 2002 07:39:18

Received: from by relay2.net.ucia.gov via smap (4.1)

        id xma026449; Fri, 1 Mar 02 07:38:55 -0500

In particular, the following data in this transcript is useful:

  • The Internet-based relay2.ucia.gov gateway has an internal IP address of and an internal DNS name of relay2.net.ucia.gov.

  • relay2.ucia.gov is running TIS Gauntlet 4.1, an application firewall (smap 4.1, which is a component of TIS Gauntlet, is mentioned in the via field).

  • puff.ucia.gov is an internal SMTP mail relay system running Sun Sendmail 8.8.8.

  • mailhub.ucia.gov is another internal mail relay running Sendmail (this can be seen from analyzing the SMTP server responses to the RCPT TO: command).

In the overall scheme of things, SMTP probing should appear later in the book because it is technically an intrusive technique that involves transmitting data to the target network and analyzing responses. I mention probing here because when users post email to Internet mailing lists, SMTP routing information is often attached in the headers of the email message. It is very easy for a potential attacker to then perform an open and passive web search for mail messages originating from the target's network space to collect SMTP routing information.