In this article, we will take a look at the complete DNS process, DNS lookup, DNS reverse lookup, DNS zone transfer, etc. along with some tools to analyze & enumerate DNS traffic.

Domain Name System (DNS) is a naming system used to convert human readable domain names like into a numerical IP address. The process works like this: Let’s assume a user types in their browser and what you see is indeed the infosecinstitute website. But what happens behind the scenes is rather interesting, like how the request got from my browser to the correct domain name?

Well, it is the job of the DNS resolver in the end user system to fetch the IP address for the requested domain. DNS settings can be managed in the following ways in end user system.

But how does the request actually change it to Well, the DNS resolver first checks the local cache to see if it contains any records for the requested IP. The local DNS cache can be checked using command:

ipconfig /displaydns

As you can see since in my cache there is already a request logged for, now for future requests, all the queries to this domain can be fulfilled from local cache until the cache is refreshed and the respective IP is mapped under A record. Now this story seems simple, but how does the cache actually get filled? Yes, you guess it right; it filled when I browse the website, but the 2nd part of the question is still not answered how it actually fetches the website in the first attempt.

In the first attempt to browse a website by domain name, DNS resolver will query the ISP DNS server to look out for records, and if it is not found there, then a recursive DNS query starts which means querying DNS servers till the records are found. These recursive servers contain their own local cache in which they will look for results. Then if the result is still not found then, the query will be directed to root nameserver from where it will be redirected to the Top level domain(TLD) name servers. TLD nameserver reads the request from right to left and directs the query to TLD nameserver such as to .com TLD. Then .com TLD looks out for next part of request like and query will be redirected to authoritative nameserver which surely has the information. For IP address, the information is A record. Remember request is still from the recursive nameserver, so the record is retrieved and stored in the local cache of the nameserver. This answer is further returned to end user computer and is stored in local cache.

Below are some important record types which can very well tell us the nature of NDS request. Some of the important Record Types are:

  • A record: Defines a host address
  • NS record: Authoritative Nameserver
  • MX record: Mail Exchange

For example, below we are using nslookup on

Here we have set type=a and type=ns to display A record and NS record. We can see that is an authoritative name server for However, we will see below that using tool like dnsEnum this all information can be retrieved by default.

For a complete list of the type of records, see here.


  • Forward Lookup: Above process that is we have mentioned is also known as Forward lookup. Take a look at below screenshot

    A very basic example is to use nslookup on, and then IP address is displayed.

    Below is another example of nslookup on which with the usage of type A & NS.

  • Reverse Lookup: As its name suggests, reverse lookup is a determination of domain name from IP address. For ipv4 address, reverse DNS lookups uses special domain for any query and is appended to the IP address for performing a reverse lookup. The reason to use a specific domain for reverse lookup is because how DNS structure is built and for reverse DNS if that structure is followed then it will take too long. This IP address is then read or with some tools mentioned in reverse order for example if we have to perform a reverse lookup for then we need to search for

For example, below we are doing a reverse nslookup on one of Google servers. As you can see that address is reversed and is appended

Below is an example of reverse lookup for infosecinstitute.

Looks like we cannot perform reverse lookup on domain ☺

DNS Analysis in Kali

As we know, Kali distro is specially assembled for pen testers and have some really cool tools available to do pen-test in just a few clicks. For DNS analysis also it has some great tools. Below are some of the tools that can be used for DNS information gathering.

  • Dnsenum

As we can see, we get all the information for infosecinstitute automatically from dnsEnum tool which having to specify the record type that we were doing in nslookup. We can see Host IP address, Nameservers, Mail Servers, etc. In its simplest usage, type dnsenum <domainname>. For more important options like no-reverse type –h as a parameter.

  • Dnsrecon

    Short for DNS reconnaissance, this tool is also present in Kali distro. Below is a screenshot of Dnsrecon in action.

    We can see that dnsrecon gives us a good amount of information on domain We can see record types like A, SOA, MX, NS, TXT and even SRV.

  • Dnstracer

    Dnstracer gives us a map of a complete request from end user machine to NS.

    Here we have the tracing like

    #end-user-machine# <—> #DNS server#<—> Google name server (ns (1|2|3|4)

DNS Structure & Packet Analysis using Wireshark

In this section, we will cover DNS structure and packet Analyses using a very powerful tool known as Wireshark. Many of you reading the article might already be familiar with this tool as it is extremely popular tool mainly because of the wide protocol it supports and for a user-friendly interface.

So let’s take a look at the complete DNS structure in the following examples.

Below is a screenshot for a standard query and response packet in Wireshark. As you can see below is a request for for Records types: Type A and Type AAAA which is simply asking host’s ipv4 address and ipv6 address respectively.

Below is a complete DNS request format for record type A

Important points to note here are:

  • Before DNS protocol notice that UDP is used for source port 54458 and destination port 53.
  • We can see the Response packet no for this query. In this case, it is 30. Also, note the transaction ID. It should match in the response packet.
  • Under Flags:
    • The first bit is set to 0 which means it is a query. Bonus points to you if you can guess what will be set for query response(See below in the response section below)
    • Next, 4 bits are set to 0000 which means that it is a standard DNS query.
    • The 8t bit is set to 1 which means that recursive queries are enabled on our DNS server.
    • 14th Bit is set to 0 which means it will accept authenticated data.
  • Under Queries, you can see that the request is made for for record type A in internet (IN) class.

Similar DNS query for record type AAAA below

Now let’s take a look at the response section. Below is a query response for an earlier query for record type A.

Important points to note in the response structure are:

  • We can see the Request query packet no for this response. Transaction ID is correctly matched to transaction ID within Request query packet.
  • Under Flags:
    • The first bit is set to 1 which means that it is a DNS response packet.
    • Recursive queries are enabled.
    • There is no error in the response query.
  • Also, there is some additional data (name servers) found in the response.
  • There are more sections to Queries and Answers which relates to what was asked from DNS and what is the response. In this example, we have queried IP address for and got the answer:
  • There are some authoritative name servers also found for infosecinstitute.
  • Under Additional Records, we can even see the IP address of these authoritative nameservers.

Below is a similar response to request query for record type AAAA.

Since there will be a lot of data flowing across the monitored interface, we can use Wireshark filter capability to automatically recognize/display only DNS packets (in this case). Below is an interface to create a new filter under Capture>Filters.

Click on + sign to create a new filter. Below is an example where I created a DNS filter to filter traffic destined for port 53.

Notice I did not mention any protocol here because I want to see both UDP and TCP for port 53. As a reminder, TCP 53 is used for zone transfer(AXFR).

Now we will see how to analyze zone transfer in Wireshark.

Below is an example of a zone transfer request to Look out for results below

Since zone transfer happens over TCP, so the first 3 packets you can see is the handshake process happening. After a successful handshake, a DNS standard query for record type AXFR is made. Below is the request query

Notice the query type under queries section. Below is the response packet for this request query.

As you can see that the reply code is 9 which means DNS server is not authoritative to get zones from authoritative name servers which result in connection termination which we can in the below connection termination sequence of TCP packets.

DNS traffic analysis adds a lot of context during the investigation, for example, we can build up Indicators of Compromise based on DNS traffic, we can detect DNS zone transfers and even an organization can look at how much information it has actually revealed about itself. With these analysis results, DNS servers can be hardened.In this article, we have also learned that how looking at DNS records like AAAA, AA; DNS lookups (both forward and reverse); Response Codes; Queries and Answers; Wireshark packet stream feature can really help to set the context for an investigation.

Original Post: