Update (06/08/2020) – APNIC has published this post on their blog. Robbie Mitchell from APNIC was of great help in correcting a few things and polishing the article. You can read the Part 1 on the APNIC blog here
DNS(Domain Name System) is the crucial & ubiquitous fabric of the Internet. While on the surface, users rely on accessing websites, apps, email etc underneath it’s the DNS database which provides the map for the Internet.
It’s fair to say that everything on the Internet begins with a DNS query. This means that the DNS is used for legitimate purposes and as well as abused by bad actors.
Adding a layer of security to a flat network
In the context of COVID-19, where most of us are working from home, security of the the devices & data being accessed from a hostile home network has become a major talking point over the last couple of months. The home network is atypical from an enterprise network from a security perspective and apart from its inherent flaws, it’s a flat network.
Here is a representation of a flat network design,
The constraints of a flat network are,
- No segmentation of traffic – Single broadcast domain
- Easy & rapid propagation of malicious traffic within the network
One of the layers of security that can be brought into a flat network at an economical cost is by leveraging DNS. Before we look into how that can be implemented, here is a DNS primer for what happens when a domain name is accessed in a network,
Shift of the recursive resolvers
In the above diagrammatic representation, the part which is doing the most heavy lifting is the Recursive DNS Server or Recursive resolver. At the very beginning of the Internet, users themselves ran recursive resolvers on the machines or in the network. This model slowly shifted to the network operators (ISP’s) offering this as a bundled, free of cost offering along with the service. And the model has moved DNS resolution further away from the user with the advent of the Cloud/Quad DNS providers. To name a notable few, Google Public DNS (188.8.131.52, 184.108.40.206), Cloudflare (220.127.116.11, 18.104.22.168), Quad9(22.214.171.124) etc.
While each of these open resolvers services promote faster dns resolution, in reality they are still further away from the user from a round trip metric. Even though all of these open resolver services use IP Anycast, the proximity to the user cannot compete with a local resolver. In obvious terms, the recursive resolver which is in the users network or even the resolver provided by the Internet Service Provider will always be closest.
The one definitive advantage that the cloud/quad DNS open resolvers provide is the availability of a large cache.
If you aren’t convinced yet on running your own DNS resolver instead of outsourcing it to the cloud/quad DNS providers, I would urge you to read Why should I run my own DNS resolver?
And most importantly, if you want to leverage DNS Response Policy Zones (DNS Firewall) to add a layer of security in your network, you need to run a recursive resolver.
What is DNS Response Policy Zones(RPZ) ?
- It’s currently an Internet-draft and not a standard yet. The latest draft is available here
- It’s a vendor neutral – BIND, Unbound, PowerDNS Recursor support it
- Allows policy to be applied to DNS queries. Set a differentiated route for the bad domains
- Economical solution – a RaspberryPi can act as recursive resolver with DNS RPZ for the entire network – especially useful & low cost solution for home networks, SOHO etc
Just like the functioning of a firewall, RPZ is made up of TRIGGERS & ACTIONS.
This is all good but without threat intelligence data, a DNS Firewall doesn’t add any value.
Threat intelligence RPZ feeds
While there are many threat intelligence providers which provide a DNS RPZ feed, below are some of the free/community ones,
Part II of this post will contain instructions for configuring a RPZ feed in ISC BIND9.