DNS Part 2: Learning Dig

A few months back, I wrote an article called DNS for Network Engineers.  Basically, it is a back-to-basics look on what each of the DNS record types were, and a few examples of what they looked like using Dig.  Well, the feedback I received was a desire for more Dig.  So I give you: Learning Dig.  I’ll show you the basics of the command, what it can be used for, and what some potential bad actors use it for.  In this case, how you can protect your DNS from known DNS vulnerabilities out there.

What is Dig?

Dig, or Domain Information Groper (creepy, I know), is a command-line tool that can be run in Windows, Mac, Unix or Linux.  Most of my examples will be on a Linux shell as that is what I use on a daily basis.  However, all of the options and switches are the same on any platform.  Dig is a great tool that was designed to test DNS.  It can produce standard queries or Frankenstein ones if you are into pen-testing DNS.

Let’s start with where to get it.  For Windows go here: http://www.isc.org/downloads/  It’s not an easy install with Windows, but Sam Bowne has a great tutorial that walks you right through it here: http://samsclass.info/40/proj/digwin.htm

For Mac, Unix or Linux, it’s even easier – it’s already installed.  By the way, good job on working on a superior operating system 🙂

Let’s get Digging

If you are unfamiliar with DNS in general, please read my previous blog on DNS Basics before continuing because it’s about to get highly technical.  Dig gives you four response sections upon a DNS query: Question Section, Answer Section, Authority Section and Additional Section.  Each one represents very important information.  The Question is a wrap up of what you just asked, the Answer is what the server responded with, the Authority is what entity is authoritative for what your answer is (we’ll have fun with this later), and the Additional section is meta info on the transaction like how long it took, what server responded and on what port and protocol.

Example 1: The basic Dig

Here we’ll just dig for Google.

dig google.com

; <<>> DiG 9.8.1-P1 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57558
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.            IN    A

;; ANSWER SECTION:
google.com.        300    IN    A    74.125.228.68
google.com.        300    IN    A    74.125.228.69
google.com.        300    IN    A    74.125.228.70
google.com.        300    IN    A    74.125.228.71
google.com.        300    IN    A    74.125.228.72
google.com.        300    IN    A    74.125.228.73
google.com.        300    IN    A    74.125.228.78
google.com.        300    IN    A    74.125.228.64
google.com.        300    IN    A    74.125.228.65
google.com.        300    IN    A    74.125.228.66
google.com.        300    IN    A    74.125.228.67

;; AUTHORITY SECTION:
google.com.        13402    IN    NS    ns4.google.com.
google.com.        13402    IN    NS    ns2.google.com.
google.com.        13402    IN    NS    ns3.google.com.
google.com.        13402    IN    NS    ns1.google.com.

;; Query time: 17 msec
;; SERVER: 10.0.0.150#53(10.0.0.150)
;; WHEN: Sun Feb  9 14:25:33 2014
;; MSG SIZE  rcvd: 276

As you can see everything seems normal.  Well let’s look into it some more and see if IPv6 might be there and maybe some mail server MX records:

dig AAAA google.com

; <<>> DiG 9.8.1-P1 <<>> AAAA google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20090
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;google.com.            IN    AAAA

;; ANSWER SECTION:
google.com.        300    IN    AAAA    2607:f8b0:4004:802::1003

;; AUTHORITY SECTION:
google.com.        10438    IN    NS    ns4.google.com.
google.com.        10438    IN    NS    ns1.google.com.
google.com.        10438    IN    NS    ns2.google.com.
google.com.        10438    IN    NS    ns3.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.        342824    IN    A    216.239.32.10
ns2.google.com.        343974    IN    A    216.239.34.10
ns3.google.com.        343974    IN    A    216.239.36.10
ns4.google.com.        343974    IN    A    216.239.38.10

;; Query time: 25 msec
;; SERVER: 10.0.0.150#53(10.0.0.150)
;; WHEN: Sun Feb  9 15:14:56 2014
;; MSG SIZE  rcvd: 192

That’s IPv6 by using the AAAA option in front.

 

dig MX google.com

; <<>> DiG 9.8.1-P1 <<>> MX google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33254
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 4, ADDITIONAL: 9

;; QUESTION SECTION:
;google.com.            IN    MX

;; ANSWER SECTION:
google.com.        600    IN    MX    50 alt4.aspmx.l.google.com.
google.com.        600    IN    MX    10 aspmx.l.google.com.
google.com.        600    IN    MX    20 alt1.aspmx.l.google.com.
google.com.        600    IN    MX    30 alt2.aspmx.l.google.com.
google.com.        600    IN    MX    40 alt3.aspmx.l.google.com.

;; AUTHORITY SECTION:
google.com.        10369    IN    NS    ns3.google.com.
google.com.        10369    IN    NS    ns1.google.com.
google.com.        10369    IN    NS    ns2.google.com.
google.com.        10369    IN    NS    ns4.google.com.

;; ADDITIONAL SECTION:
aspmx.l.google.com.    293    IN    A    173.194.68.26
alt1.aspmx.l.google.com. 293    IN    A    173.194.78.26
alt2.aspmx.l.google.com. 293    IN    A    173.194.65.26
alt3.aspmx.l.google.com. 293    IN    A    173.194.70.26
alt4.aspmx.l.google.com. 293    IN    A    173.194.69.26
ns1.google.com.        342755    IN    A    216.239.32.10
ns2.google.com.        343905    IN    A    216.239.34.10
ns3.google.com.        343905    IN    A    216.239.36.10
ns4.google.com.        343905    IN    A    216.239.38.10

;; Query time: 24 msec
;; SERVER: 10.0.0.150#53(10.0.0.150)
;; WHEN: Sun Feb  9 15:16:05 2014
;; MSG SIZE  rcvd: 352

Now we can see some MX records.  Let’s dive a little deeper.  Can I use one of their Name Servers (ns1.google.com) to resolve non-authoritative records like yahoo.com?

dig @ns1.google.com yahoo.com

; <<>> DiG 9.8.1-P1 <<>> @ns1.google.com yahoo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17177
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;yahoo.com.            IN    A

;; Query time: 24 msec
;; SERVER: 216.239.32.10#53(216.239.32.10)
;; WHEN: Sun Feb  9 14:28:40 2014
;; MSG SIZE  rcvd: 27

Nope!  That’s where we see “Refused” and “recursion not available.”  This means I can’t use this server to find out records for other DNS zones out on the Internet.  As a side note, this vulnerability almost crippled residential internet in France last year. Attackers saw that France Telecom was rolling out cable modems with DNS recursion turned on.  So that’s why it’s always a good test for network engineers to test their public DNS and try to resolve through it for records it doesn’t own.  That command again was: dig @<your DNS server> <a domain you don’t own>  If you get anything other than REFUSED it’s broken and needs fixing.

If your DNS server is BIND like most of the Internet, it’s easy to fix.  Basically add this to your named.conf file:

options {
    recursion no;

If you use that same server for recursion on your local network too, then there’s a slight modification to that.  However, if you are doing that, I refuse to contribute to that ridiculous engineering, so go find that somewhere else.

However, Google does offer a public DNS resolver with the anycast address of 8.8.8.8.  It will resolve anything.  It’s a good test to see of DNS is broken for just you or everyone else too:

dig @8.8.8.8 yahoo.com

; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 yahoo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8904
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;yahoo.com.			IN	A

;; ANSWER SECTION:
yahoo.com.		477	IN	A	206.190.36.45
yahoo.com.		477	IN	A	98.138.253.109
yahoo.com.		477	IN	A	98.139.183.24

;; Query time: 17 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Feb  9 15:18:22 2014
;; MSG SIZE  rcvd: 75

 

Example 2: More advanced Dig

Let’s say you want to just simplify the result to exactly what you ask.  Try this:

dig +nocmd +noall +answer AAAA google.com
google.com.        275    IN    AAAA    2607:f8b0:4004:802::1000

This gives us just what we wanted with none of the fluff.  Now here’s one that you will likely use to help troubleshoot DNS problems: tracing.  The output we get is based on all the hops and from whom is answering:

dig +nocmd +trace AAAA google.com.            357629    IN    NS    a.root-servers.net.
.            357629    IN    NS    k.root-servers.net.
.            357629    IN    NS    h.root-servers.net.
.            357629    IN    NS    m.root-servers.net.
.            357629    IN    NS    f.root-servers.net.
.            357629    IN    NS    g.root-servers.net.
.            357629    IN    NS    e.root-servers.net.
.            357629    IN    NS    b.root-servers.net.
.            357629    IN    NS    c.root-servers.net.
.            357629    IN    NS    i.root-servers.net.
.            357629    IN    NS    l.root-servers.net.
.            357629    IN    NS    j.root-servers.net.
.            357629    IN    NS    d.root-servers.net.
;; Received 512 bytes from 10.0.0.150#53(10.0.0.150) in 940 ms

com.            172800    IN    NS    a.gtld-servers.net.
com.            172800    IN    NS    b.gtld-servers.net.
com.            172800    IN    NS    c.gtld-servers.net.
com.            172800    IN    NS    d.gtld-servers.net.
com.            172800    IN    NS    e.gtld-servers.net.
com.            172800    IN    NS    f.gtld-servers.net.
com.            172800    IN    NS    g.gtld-servers.net.
com.            172800    IN    NS    h.gtld-servers.net.
com.            172800    IN    NS    i.gtld-servers.net.
com.            172800    IN    NS    j.gtld-servers.net.
com.            172800    IN    NS    k.gtld-servers.net.
com.            172800    IN    NS    l.gtld-servers.net.
com.            172800    IN    NS    m.gtld-servers.net.
;; Received 488 bytes from 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30) in 650 ms

google.com.        172800    IN    NS    ns2.google.com.
google.com.        172800    IN    NS    ns1.google.com.
google.com.        172800    IN    NS    ns3.google.com.
google.com.        172800    IN    NS    ns4.google.com.
;; Received 164 bytes from 192.54.112.30#53(192.54.112.30) in 269 ms

google.com.        300    IN    AAAA    2607:f8b0:4004:802::1004
;; Received 56 bytes from 216.239.38.10#53(216.239.38.10) in 19 ms

In this one, I asked my local DNS server (10.0.0.150) what is the AAAA for google.com.  I was given a list of all the TLD root servers, then I asked the root servers, they replied with the NS record for google.com and I asked and it replied with the record.  All of which took 19 milliseconds.

Example 3: Pen-testing with Dig

A problem with DNS today is that most of it is too trusting.  More folks are moving to DNSSEC which does authenticate domains with signed keys, but most domains out there still don’t have it enabled.  So this leads to problems with DNS man-in-the-middle or poisoning attacks,  Let’s say I come across a pretty insecure domain server and I realize not only is recursion enabled, but zone transfers are as well.  So I use Dig to transfer the zone to a rogue server I build out in Amazon’s EWS cloud.  All I do is this:

dig axfr tachyondynamics.com 127.0.0.1

And if I get something other than “transfer failed” then I just downloaded the entire zone file for that domain.  From this point on I can do all kinds of nefarious things that I will not elaborate on here.

If you really want to get into pen-testing with DNS there’s a pretty cool Perl tool called Fierce that packs quite a punch with all of the things you can “test.”  Good tutorial here.

Wrap up

In summary, Dig and other tools out there, can help you as a network engineer troubleshoot the heath of your network and identify potential security issues with your network DNS as well.  Let us know if you have any questions, or need help building or securing your DNS today! Contact Us!

 

Scroll to Top