How I Use Farsight NOD RPZ (Newly Observed Domains) in my DNS FIrewall

Over at my day job we've created a Newly Observed Domains service which tracks domain first sightings and packages them up in various ways that can be used to determine network reputation. As in most advanced DNS-related technologies, my home and guests and family are guinea pigs early adopters scratch monkeys for the new tech. Here, I'll share some recipes.

It's old home week. Everything begins with a cron job on my family's FreeBSD server.


* * * * * sh ~/nod/cronrun.sh


This says, run the designated shell script once a minute. This is pretty often, as cron jobs go. But since we're talking about newly observed domains, we need to retrieve them as practically soon as they've been observed, or else they'll become a-while-ago observed domains before we can use them. The NOD data is generated once per minute, so there's no point to trying to fetch it more often than once a minute -- and doing so would likely subject me to rate limit penalties. That shell script is pretty simple:


rsync -a rsync.example.net:nod ~nod/
rndc -s ss reload 10m.rpz.dns-nod.net 2>&1 | egrep -v 'zone reload up-to-date|zone reload queued'


The rsync.example.net:nod string is a placeholder for the string that was told to me by Farsight's operations team and represents their data source. (This is a commercial product; contact sales@farsightsecurity.com to learn more about it.) I've broken some rules by putting production infrastructure into my home directory, but breaking rules is often part of a fast start. Also, the cobbler's children are sometimes barefoot. Note well: rsync is the wrong tool for this, and NOD-RPZ will soon be made available using the DNS transfer protocol (AXFR/IXFR, with NOTIFY and TSIG), and rsync will be pushed not pulled. Right now it's an EFT (external field test) on the data itself not the channel by which it's published.

Since the particular NOD service I'm using is the 10-minute RPZ which lists newly observed domains for their first 10 minutes after first observation, that's the file I'm telling ISC BIND9 to reload after every rsync. Fortunately ISC BIND9 is smart enough to treat this as a no-op if the zone file has not changed. (Notably, unless something is wrong, the file has always changed after one minute.) Just as fortunately, rsync is smart enough to only send file differences when possible, so the network traffic load here is quite light. Finally, I'm filtering out zone reload up-to-date and zone reload queued messages, which are indications of health. Anything not filtered out becomes the cron job's standard output, which cron will send to me via e-mail.

The ISC BIND9 configuration for my recursive name server is long and tortuous, so I'll just pull in some relevant excerpts:


options {
  ...
  response-policy {
    zone "10m.rpz.dns-nod.net";
    ...
  };
};
...
zone "10m.rpz.dns-nod.net" {
  type master;
  also-notify { 2001:559:8000:ca::5e; };
  file "/home/vixie/nod/nod/rpz/10m.rpz.dns-nod.net.zone";
};


What this does is load up a zone called 10m.rpz.dns-nod.net from the file in my home directory that's created by rsync running from that cron job up there, notifies my other local name server whenever a new zone has been loaded, and then uses the content of this zone as DNS Firewall (RPZ) rules. Let's look at an example, which will obviously not still be valid by the time anybody reads this.


$ grep CNAME ~/nod/nod/rpz/10m.rpz.dns-nod.net.zone | head -1
digitalcelerity-education.com IN CNAME . ; first_seen=1396560324
*.digitalcelerity-education.com IN CNAME . ; first_seen=1396560324



$ dig www.digitalcelerity-education.com
;; ->>HEADER ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; AUTHORITY SECTION:
10m.rpz.dns-nod.net. 300 IN SOA a.rpz-ns.dns-nod.net. nod-admin.fsi.io. 1396560844 600 300 86400 300
;; SERVER: 2001:559:8000:cb::2#53(2001:559:8000:cb::2)


What this means is, the first non-test RPZ rule found in the 10-minute NOD RPZ was digitalcelerity-education.com, and when I asked my name server for a subdomain of it (www.digitalcelerity-education.com) it lied to me, with attribution, by telling me that this domain did not exist. I checked with whois and learned:


Domain Name: DIGITALCELERITY-EDUCATION.COM
...
Creation Date: 02-apr-2014


Which is "yesterday" from my point of view writing this blog post, so it's reasonable that Farsight NOD only just now got its first sighting. Note that NOD often sees things for the first time after they have existed for weeks or months, so there's no reason to presume criminal intent just because a domain was listed in NOD. However, actual criminals make huge early use of new or young domain names, and putting them into a 10-minute "you do not exist yet as far as I'm concerned" penalty box should make us safer.

NOD is available in a lot of other time domains (5 minute, 30 minute, 1 hour, 3 hour, 12 hour, and 24 hour) so if 10 minutes isn't the right size penalty box I have choices. NOD is also available in rbldnsd format, about which, more later.