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!