Ten years ago today at a “secure off site meeting” ( i.e. in the pub ) I asked a colleague if there was any reason why we couldn’t use DNS load balancers to “load balance” bad domains to an address of our choosing. After some thought there didn’t seem to be any reason why we couldn’t do it or why it wouldn’t work. So the next morning as it still seemed like a good idea we added load balancing rules for three choice domains with less than savoury reputation. This quickly proved to be quite a successful tactic so we dubbed it “the naughty step”, and assumed that as it was such an “obvious” thing to do loads of other people must also be doing it.
After we’d been going on like this for a while Paul Vixie published his excellent article on taking back DNS, which gave us a hint that maybe it hadn’t been quite such an obvious idea after all. We had by this point quite a few domains on the naughty step, and by sending all the traffic to an “informational” web server it was both generating useful information and proving to be an excellent way of educating users ( and generating excuses from the same users ). The continuing success of our “naughty step” included such highlights as not being amongst the major corporations downloading leaked Facebook data – thanks to the major torrent sites being redirected. Somewhat after this event our user base finally started asking about why some domains weren’t going where they expected. This prompted us to “officially” rename it from “naughty step” to “proactive cache poisoning” as that sounded more professional and business friendly. We had by this point realised that it was also an effective tool for blocking certain unwelcome applications.
After three years of using a very laborious process to maintain the rules on DNS load balancers I managed to implement suitable logic using the LUA back-end provided by PowerDNS recursor. Whilst RPZ functionality had just been released in BIND that didn’t fit as well with our infrastructure ( as we weren’t using BIND ). I did steal the idea of distributing the blocking information via zone files – but was using a script to convert the zone file into something more suitable for our LUA back-end. This move also allowed the security team to be able to add and remove records directly via a light weight tool.
Eventually all good things come to an end and in 2013 an addition of a few thousand extra domains brought our home grown solution to it’s knees. Whilst rewriting the LUA script did allow us to cope it was obviously time to move to a commercial supported solution, which thankfully was now available. With the move to a commercial implementation we were able to really start taking full advantage of the capabilities of the RPZ concept. Apart from the obvious uses of block malicious domains and the connectivity of some unwanted applications, it’s also become a vital part of our tool-kit to :
- Redirect NTP traffic to internal time servers
- Reduce the number of junk requests we send to the root name servers
- Creating split DNS for individual records during acquisitions and divestitures
- Monitoring specific domain queries, to look for typo’s or misconfigurations etc.
In 2017 we finally closed the missing link in our RPZ chain, when I realised that if you aren’t running the RPZ on all of your internal DNS servers then it’s probably a good idea to automate flushing the cache of those other servers when you add something to your RPZ. Again something that seems obvious once you think of it and it only took me eight years. All of which brings us almost up to date – except to curse the names of those that invented DNS over HTTPS and decided to make it particularly hard to block ( I’m looking at you Google and Mozilla ) thus massively reducing the effectiveness of the RPZ and any DNS based security measures. However despite the challenges the DoH! is going to bring us I think the RPZ will continue to prove an invaluable tool both in security and non-security related situations for well configured users and applications.