DNSTRACER

Welcome to another tutorial for tools used in DNS enumeration/analysis! This tutorial is on DNSTracer, which was written by Edwin Groothuis.

DNSTracer isn’t like the other tools we’ve looked at. It isn’t going to give you super cool results that will let you pwn a machine and take over the world. Instead, think of it kind of like running a traceroute for DNS. It allows you to see the “path” a request takes to get the authoritative answers for your domain. If you saw the tutorial on how DNS works on the internet, you’ll have a pretty good idea of how dnstracer works. Obviously, there’s a lot more going on behind the scenes when a request is made, but you can still get a picture of how your zone information is being delegated out to the other servers.

To open the program within Kali, go to “Applications –> Information Gathering –> DNS Analysis –> dnstracer”. This will launch a terminal window, and show the available options for the tool.

dnstracer-help1

This gives you the standard listing of options, with a basic description of what each does. You can also view the man page, which offers a bit more detail on how everything works:

dnstracer-manpage

Default Scan
The first thing we’ll do is run a default scan only using the -v, and -o options. By default, it will send a query for the A records of the domain, but we’ll also look at some of the other RR types.

To run the first scan, just type the following:

dnstracer -v -o msn.com

which gives you the following results:

dnstracer-defaultscan1
dnstracer-defaultscan2

The “-v” option is for verbosity, which causes it to show the requests and answers going back and forth. The “-o” option gives a summary of the answers at the end of the scan.

You can see that it begins by sending the request to the default resolver, which in this case is an OpenDNS server. It shows the information contained in the DNS packet, and the answers it received.

Just to take it a step further, let’s fire up Wireshark so you can see what the DNS requests look like going over the wire. Go to “Applications –> Sniffing and Spoofing –> Wireshark“.

If you’re not familiar with Wireshark, it’s a tool that allows you to capture packets as they go across your local network. It lets you see the requests and responses for different traffic types such as HTTP, DNS, FTP, etc.

Once Wireshark is open, select your interface, then start the packet capture. You can add a filter to just see the DNS traffic, by typing in “udp.port==53” into the Filter box. Click “apply”, and you’ll only see DNS traffic. Now run the same scan, and see what comes up in Wireshark.

dnstracer-wireshark1
dnstracer-wshark-msn1
dnstracer-wshark-msn2
dnstracer-wshark-msn3

Take some time to look at each of the packets, and see the information that gets passed back and forth during the requests.

Specify Query Type
Now let’s run a scan by adding in the “-q” switch to specify a query type. Like I said earlier, if you don’t use this option, the default resource record type is “A”. You can either type those specific text labels such as MX, SOA, or NS, or you can use the numerical value. MX would be 15. If you’re a glutton for reading RFC’s, IANA maintains a list of all the DNS RR types with their values at the following page:

http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

The first query we’ll run will include the SOA for msn.com. For this scan, we’ll use these options,

dnstracer -q soa -o -4 msn.com

dnstracer-soa1

Here we see the SOA returned, which includes the serial number, mname, and rname. The mname value shows the primary server for the domain, and the rname value is the email address for the person responsible for the domain.

Let’s change the query type to NS…

dnstracer-ns1

And, MX records…

dnstracer-mx1

You can see that we can still extract some info about the domain by specifying certain resource records in the scan.

Change Initial DNS Server
Now let’s look at changing the initial server it uses for the requests. We’re going to use the “-s” option, and point it to the DNS root servers. You do this by just putting a “.” in as the value for the option.

dnstracer-rootsrv1
dnstracer-rootsrv2

You see that it queries the root server, and the request then makes it to the TLD servers. In this case, the answers are shown to be cached. The scan ends, and shows us the A records for MSN.

Conclusion
DNSTracer seems to be geared more for sysadmins to use, if they need to troubleshoot DNS delegation issues, and want to see how their zone data is being propagated. The other options available deal more with a local DNS server. For instance, the “-C” option enables negative caching, which is where a DNS server will cache a response for an invalid host query.

Thanks for checking out the tutorial! Be awesome!