Watching those DNS logs

Published: 2008-08-05
Last Updated: 2008-08-05 22:43:06 UTC
by Daniel Wesemann (Version: 3)
2 comment(s)

Among the frantic activity to get all the DNS resolvers patched, very little has been said on how to be on the lookout for DNS poisoning attempts. Irrespective of the attack details, the two possible scenarios seem to be
(1) someone attacks a DNS resolver/forwarder of yours
(2) someone attacks a remote resolver/forwarder to poison a domain you own
The impact of the first scenario would be to draw your own users from, say, to an evil incarnation instead. The impact of the second scenario would be that a customer of yours somewhere else on the world can no longer get to your services and is being redirected to or through an evil third party. The first scenario is what you patched your resolvers against - for the second scenario, you have to hope that all your customers are patched. If you are, for example, a retail bank with a nationwide online presence, chances are that not all your clients (or rather their ISPs) are patched and safe.

From the attack details that have so far been disclosed, scenario (2) involves a high number of queries for bogus names in the domain that you own. Your authoritative DNS server will respond with "NXDOMAIN" (no such domain) to all these requests, but every such query provides the attacker with a chance to inject a bogus reply to poison the querying resolver of your client's ISP. has a Snort rule (sid:2008470) to catch an excessive number of NXDOMAIN replies received by your resolver. This covers scenario (1). Scenario (2) would require a way to watch for a high number NXDOMAIN answers sent by your own authoritative DNS server. A quick check we made turned out that neither BIND9 nor MS-DNS seem to offer any easy way to log NXDOMAIN answers of your DNS server without going into debug-dump-it-all mode. The statistics collected by BIND keep track of sent NXDOMAIN records in the "SNXD" counter, but that's about it.

If you have any good suggestions on how to watch for a high number of queries for nonexisting hosts in your domain, or for a high number of NXDOMAIN replies leaving your DNS server, please let us know.

Update 1100UTC:   The tool "DSC" from DNS Measurement Factory was recommended as a means to chart what is going on with your DNS server.  Since this tool is based on grabbing DNS traffic via libpcap, it can easily be combined with a shadow-style pcap collector that only stores NXDOMAIN responses. Lacking direct NXDOMAIN logging support from within the DNS daemon itself, this combination seems like a good option.

tcpdump -s1514 -nX 'udp and port 53 and (udp[10] & 128 = 128) and (udp[11] & 3 = 3)'  captures DNS responses (QR bit set) with an RCODE of 3 (no such name). See RFC1035 for details on the DNS record format.

Update 1530UTC: One more tip that we got involves using "tshark" from the Wireshark package to quickly extract and analyze DNS oddities from a PCAP file. The command below results in a sortable list in "IP,domain-queried" format that can be easily post-processed from a shell script

tshark -t ad -e ip.dst -e -E separator=, -T fields -nr new.pcap dns.flags.rcode == 3

Further, Snort users that subscribe to VRT rules can use SID 13948 and 13949 to watch for a high rate of NXDOMAIN responses.

Keywords: dns logs
2 comment(s)


While I dont have a good answer to this logging problem yet. There is a Splunk app, which monitors DNS activity on Bind servers. The link is:
Use Sagan. Sagan rules are a lot like Snort but is used for log analysis instead of packet analysis.

In this case, I'd create a rule (if one doesn't already exist!) to watch for a high number of NXDOMAIN's. To do this, I might do something like this:

alert udp $EXTERNAL_NET any -> $HOME_NET $DNS_PORT (msg:"Large number of NXDOMAIN detected"; content: "NXDOMAN"; parse_src_ip: 1; parse_port; classtype: suspicious-traffic; program: named; after: track by_src, count 100, seconds 30; threshold: type limit, track by_src, count 5, seconds 300; sid: 999999; rev:1;)

If Sagan "see's" 100 NXDOMAIN from the program bind ("named") in 30 seconds, it will sound off an alarm. In order not to flood you console (for example, Snorby) with millions of these events, we'll threshold after 5 alerts are sent in a 5 minute period.

Keep in mind, this rule is off the top of my head. However, it should give you a good idea about real time detection of rapid NXDOMAINs.

More information on Sagan can be found at

Diary Archives