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.comThe important part of that information is the domain servers.
Domain servers in listed order:
NS1.SOME-DOMAIN.COM
NS2.SOME-DOMAIN.COMThe 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 axfrOr alternatively with nslookup:
nslookup
> server ns1.some-domain.com
Default Server: ns1.some-domain.com
> set type=any
> ls -d some-domain.comIf 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?
I'm happy to report that I once again survived my trip to Thailand. I deftly maneuvered myself through buckets of booze (pictured on left), hordes of hungry temple monkeys (below), and crazy drunken taxi drivers (something you don't want to see). In the process I managed to meet some great people, make several fantastic contacts, and might even end up with a couple of job offers after all!
Additionally, I have an update on my previous report regarding Thailand's Internet Filtering. There is a blog, FACT - Freedom Against Censorship Thailand, dedicated to the dissemination of information regarding Thailand's filtering. (Thanks Ed!) One of the interesting things they provide, is the secret block list compiled by MICT and pushed down to all of the ISPs in Thailand.
