DNS is a key element of the Internet and, regularly, we read new bad stories. One of the last one was the Department of Homeland Security warning[1]  about recent DNS hijacking attacks[2]. Indeed, when you want to visit the website 'isc.sans.org', you must be sure that the visited server will be 204.51.94.153 and not a malicious one controlled by a malicious server. From an end-user point of view, we have to rely on the DNS. it’s not easy to detect unexpected changes but you can implement your own checks to tracks changes for your most visited websites. But from a website owner or network admin perspective, it is indeed a good practice to ensure that DNS servers authoritative for our domain zones are providing the correct information. At the Internet Storm Center, we must be sure that any request to resolve 'isc.sans.org' will always return the right IP address! 

To monitor DNS records for unexpected changes, you can use some plugins available in Nagios[3] (or any compatible tool like Icinga). You don't need to install a complete Nagios instance, just the plugins. The one that is interesting is 'check_dns'. It can check if the returned IP address for a FQDN is the expected one. We can also check if the DNS we used is authoritative for a zone:

$ ./check_dns -H isc.sans.org -s 8.8.8.8 --expected-address=11.22.33.44
DNS CRITICAL - expected '11.22.33.44' but got '204.51.94.153'
$ ./check_dns -H isc.sans.org -s 8.8.8.8 --expected-address=204.51.94.153
DNS OK: 0.141 seconds response time. isc.sans.org returns 204.51.94.153|time=0.141161s;;;0.000000
$ ./check_dns -H isc.sans.org -s 8.8.8.8 --expect-authority
DNS CRITICAL - server 8.8.8.8 is not authoritative for isc.sans.org

But monitoring single DNS entries is complex because you may have thousands of records in a single zone. If you DNS is changed, the SOA[4] record (or 'State of Authority') will be changed (at least the serial number). 

Here is the current SOA record of the zone sans.org:

$ host -t soa sans.org
sans.org has SOA record dns21a.sans.org. hostmaster.sans.org. 2019012901 7200 900 1814400 3600

A best practice is to keep the serial number format like this: YYYYMMDDNN (where ’NN’ is the number of change performed this day). If somebody has access to the zone and modifies it, the serial MUST be upgraded to let know to other DNS servers that the zone changed. How to monitor this?

First, we can use simple Bash commands. We get the SOA record, hash it, store the new hash and compare it with the previous one.

$ [ `host -t soa sans.edu | sha256sum | awk '{ print $1 }' | tee hash.txt.new` == `cat hash.txt 2>/dev/null || echo __undefined__` ] || \
    echo "SOA record changed"; \
    mv hash.txt.new hash.txt
SOA record changed

This command can be executed at regular interval via a cron job.

Easy but not very convenient. The next idea is to use OSSEEC[5] (yes, I love this tool!). OSSEC can monitor regular log files but it can also monitor the output of commands and make a 'diff' of the output between two runs. Let’s check the SOA record of sans.org:

Let’s define a new “log file” of type “command”:

<localfile>
  <log_format>full_command</log_format>
  <frequency>60</frequency>
  <command>host -t soa sans.org</command>
</localfile>

And create the corresponding alert:

<rule id=“10001" level="7">
  <match>ossec: output: ‘host -t soa sans.org'</match>
  <check_diff />
  <description>SOA record changed in zone sans.org.</description>
</rule>

Based on this alert, any change in the SOA record will be logged and injected into your regular alerting process (email notification, forward to a SIEM, etc).

Those techniques can be used to detected suspicious change into a DNS zone via a compromized admin account or a badly protected name server but they do NOT protect against other attacks like cache poisoning of a specific DNS server! And you? Do you have other techniques to keep an eye on your DNS zones? 

[1] https://cyber.dhs.gov/assets/report/ed-19-01.pdf
[2] https://www.crowdstrike.com/blog/widespread-dns-hijacking-activity-targets-multiple-sectors/
[3] https://www.nagios.org/
[4] https://en.wikipedia.org/wiki/SOA_record
[5] http://www.ossec.net

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key