Basic DNS Auditing

I seem to run across alot of security consultants and professionals that just don't seem to have a basic understanding of DNS and what sort of basic things to look for when performing an audit. I previously posted a high level guide on DNS best practices, so this posting is meant to demonstrate the technical methods for checking some of these things. This guide only provides a basic starting point and by no means is complete and exhaustive.

The first thing I like to do when externally examining someone's DNS configuration is to perform a whois on the domain name.

# whois some-domain.com

The important part of that information is the domain servers.

Domain servers in listed order:

NS1.SOME-DOMAIN.COM
NS2.SOME-DOMAIN.COM


The other things I like to check is that the contact information is semi-generic. The place this comes in handy, is in an enterprise environment where there will enevitabley be employee turnover. If the contact information is spefic to a single user, i.e Billy J. Bob, billy.bob@some-domain.com, etc, then it becomes very painful to update this information or have changes made once that employee leaves the company. I instead prefer to see something more along the lines of hostmaster@some-domain.com or dns@some-domain.com which is a distro list pointing to operations team Billy Bob is apart of.

The next thing I check, is that the NS records supplied for that domain by the name servers, match those supplied by the whois record.

dig ns @NS1.SOME-DOMAIN.COM some-domain.com

;; QUESTION SECTION:
;some-domain.com. IN NS

;; ANSWER SECTION:
some-domain.com. 7200 IN NS ns1.some-domain.com.
some-domain.com. 7200 IN NS ns2.some-domain.com.


Any mismatch between the NS records supplied by the name server and those listed in the whois record can cause intermittent DNS resolution failures and sometimes even mail delivery problems.

For redundancy purposes, the supplied domain servers should be located in geographically diverse regions on seperate networks, and should also be carrier diverse as well. Resolving these server names and performing traceroutes to each of them should allow you to make educated inferences into whether this is true or not.

Now its time to examine the DNS servers themselves. I first like to check to see if the DNS servers will provide version information. There are two ways to do this. With dig:

dig @ns1.some-domain.com version.bind txt chaos
;; ANSWER SECTION:
VERSION.BIND. 0 CH TXT "8.3.4-REL"

Or alternatively with nslookup:

nslookup -type=txt -class=chaos version.bind ns1.some-domain.com
VERSION.BIND text = "8.3.4-REL"

The easiest way to obscure this information on a server running BIND, is to use the version statement within the options section of the named.conf file.

options {
version "None of Your Business!";
}

The next thing to check is if zone transfers are enabled. Again, there are two ways to do this. With dig:

dig @ns1.some-domain.com some-domain.com axfr


Or alternatively with nslookup:

nslookup
> server ns1.some-domain.com
Default Server: ns1.some-domain.com
> set type=any
> ls -d some-domain.com

If zone transfers are enabled, you will see something similar to the dig output below:

;; global options: printcmd
some-domain.com. 3600 IN SOA ns1.some-domain. admin.some-domain. 4 900 600 86400 3600
some-domain.com. 3600 IN NS ns1.some-domain.com
some-domain.com. 3600 IN NS ns2.some-domain.com
some-domain.com. 3600 IN MX 10 mail.some-domain.com.
mail.some-domain.com. 3600 IN A 208.209.251.12
www.some-domain.com. 3600 IN A 208.209.251.243
ns1.some-domain.com. 3600 IN A 208.209.251.8
ns2.some-domain.com. 3600 IN A 208.209.251.9
some-domain.com. 3600 IN SOA ns1.some-domain. admin.some-domain. 4 900 600 86400 3600
;; Query time: 681 msec
;; SERVER: 208.209.251.11#53(208.209.251.11)
;; WHEN: Tue Sep 11 10:04:12 2007
;; XFR size: 6 records (messages 6, bytes 429)

Remember to also check for zone transfers for the reverse DNS as well:

dig @ns1.some-domain.com 251.209.208.in-addr.arpa axfr

To prevent unauthorized zone transfers, use the allow-transfer statement within the options section of your named.conf file.

allow-transfer { ns2.some-domain.com; };

Alternatively, TSIG (Transaction SIGnature) keys can be used to authenticate zone transfer requests.

All domains should also have at least two MX records for redundancy. Like DNS servers, these servers should be on separate netblocks, and be both geographically and carrier diverse.

dig ms @ns1.some-domain.com some-domain.com

Another good thing to check for, are the presence of SPF records. To do this with dig:

dig -t TXT some-domain.com +short
"v=spf1 mx ?all"

One more common mistake is to have your public authoritative nameservers configured to allow recursion. The simplest way to check for this, is to use nslookup to send a non-related request to that server. For example:

nslookup www.monkey-house.org ns1.some-domain.com

Server: ns1.some-domain.com
Address: 208.209.251.11#53

Non-authoritative answer: Name: www.monkey-house.org Address: 216.98.141.250

For more intensive testing, I also like to run the domain through tools such as:

DNS Report - http://www.dnsreport.com

So, how are you auditing DNS? What are your favorite tools?