Skip to content

Recon Part 2 – Fierce, nslookup, and dig


Fierce is a DNS brute-force scanner which comes bundled with the Kali Linux distro. Since we’re not using Kali let’s get and configure fierce from the github project’s page:

First, let’s create a ‘Recon’ folder where we will put our tools. Now that we’ve created our recon folder, let’s get this cloned over. Make sure you’ve installed git (apt-get install git, for instance). Run the following from your ‘recon’ folder to clone the fierce repository there.

After you have cloned it navigating inside. There will be a perl script we want to make executable so do the following:

Now you can run fierce from the commandline.

Before we run in to any scans, lets look at what this tool can do by first running a -h on it:

As can be seen, we’ve got a good set of options to test out! Before testing, let’s look at what fierce does with a typical scan:

  1. Attempt to do a zone transfer of target domain. This usually will not work and, if it does, it’s usually because of a misconfiguration. If successful, it will present all configured subdomains for the target DNS domain. If not, fierce will move to step 2.
  2. Start brute force scan against target domain. This will use either the builtin or a manually specified wordlist and request dns information for each subdomain tried from that list.
  3. If a subdomain receives a dns response, report a hit and the IP it resolves to.
  4. Once the scan completes, report interesting subnets related to the hits.

Using Fierce – Part 1

Let’s start by doing a basic scan with no extra options and try it against a beloved nerd site, XKCD, the command we will use is: perl -dns -threads 4

This scan will use the builtin subdomain wordlist and check each option against, here’s the first part of our scan output:

This is phase one of the scan. It first determined the primary name servers for XKCD (this is often owned by 3rd parties and not the target itself, your DNS queries will often terminate against these). It then attempts zone transfers against those servers; this rarely works but it is great when it does. Once those steps are done the final check is for a wildcard A record, this record, if it exists, will resolve any subdomain not manually specified to an IP address. For those not familiar, here’s a sample set of DNS A records for a site:


*       A     a.b.c.d
www     A     a.b.c.e
dev     A     a.b.c.f

If these records existed for a site called here is how the IP resolutions would work out:   resolves to IP a.b.c.e      resolves to IP a.b.c.f   resolves to IP a.b.c.d

The reason ‘temp’ resolves to a.b.c.d is because in DNS a value of ‘*’ (also known as a wildcard record) means ‘unless otherwise specified in DNS, resolve a subdomain to this IP address. This type of record mostly defeats brute-forcing subdomains because each record would return a value so it would look like each entry exists. However, by doing looking for different values you can still potentially extract valuable information. In the previous example the fact that ‘,,’ all resolve to a.b.c.d while ‘’ resolves to a.b.c.f might indicate that a.b.c.f is a legitimate subdomain while the others may or may not be.

Using Fierce – Part 2

Now we’ll take a look at the second part of this scan:

So this scan found 11 entries from the 1594 words we checked. Some of them have multiple entries because of load-balancing, misconfigurations, or other reasons. Despite most of these being related to mobile one of these provides us with a ton of information! I decided to check out to see what was there, this is what came up:

At a glance it looks like some of these could be subdomains which fierce didn’t detect, this leads us to a few other utilities of use, dig and nslookup. Remember that fierce is using a wordlist and that unless the subdomain is on the wordlist, it will not be detected. Always be looking to improve your wordlists and keep in mind that the more items on the list, the longer it takes to scan.

The dig command is primarily used to query DNS servers and nslookup does forward and reverse DNS lookups. We’ll start with nslookup as it is a bit simpler to use:

This snippet shows launching the nslookup utility, checking  the subdomain, getting no result, checking the subdomain, getting a CN and A record response.

This first part indicates the server queried and the port it was queried on (53 which is the standard for DNS). The last line indicates there was not a successful lookup for

The second attempt is successful and here’s the breakdown:

The queried server and port remains the same, which is to be expected and then we get a few lines:

canonical name refers to a CNAME record which is, essentially, a redirect. In this case if a query comes in for it redirects that request to There are then two more CNAME records which ultimately land the request at which is at IP as seen by the last A record.

NSLookup also has a verbose mode which shows a more comprehensive conversation. To enter this mode, after launch nslookup type set d2 and then input your query. Here’s the result from

I highly recommend getting to know nslookup – it is available by default in most Windows, Linux, and OSX systems.

The second tool, which does a very similar thing, is called dig. Here’s what it looks like:

As you can see in the ‘Answer’ section the results are similar to what we found in nslookup and contain some extra information like the TTL for the records. Get to know these tools.

Using Fierce – Part 3

Lastly, going back to fierce, let’s examine the last section of the output:

After returning the IPs we receive some useful data about the networks the results came in on. Were you doing a pentest for a company this might give you an idea of where their public IP space is and could warrant investigating nearby IPs for content with unexpected DNS names or which may only be using the IP address without DNS names, it is not uncommon to see this.

Using Fierce – Part 4

Many of the options in Fierce are useful and I just wanted to include an overview of a few of them here.

  1.  wordlist – this flag will let you point to a wordlist file which is a line-separated file of words to test for subdomains. There are some great files out there which I recommend searching for to use in place of the builtin hosts.txt file that comes with fierce
  2. connect – This will attempt to make an http connection to each of the tested subdomains and returns the headers.
  3. delay – this specifies a delay, in seconds, to wait between queries
  4. dnsserver – choose specific dns server(s) to query through
  5. file – output the results to a file

What are you favorite custom scans?

The next post will cover a few more recon tools such as gobuster, eyewitness, and metagoofil! As always, comments and criticisms are appreciated!

Next post is up: Gobuster and EyeWitness

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *