The Domain Name System (DNS) is a crucial component of the Internet.
It’s most well known as the system that maps names to IP addresses but has also grown to support many important applications including email authentication protocols and Domain Name Security Extensions (DNSSEC).
Unfortunately, like all things important, it has also become a target for abuse by malicious actors, which is why it’s worth looking at ways to secure it, particularly if you run your own resolver.
Adding a layer of security to a flat network
The COVID-19 pandemic has forced many of us to work from home, leading to many network and information security experts questioning the security of BYO devices and the data being accessed from vulnerable home networks.
From a security perspective, the home network is atypical from an enterprise network. Apart from its inherent flaws, it’s a flat network.
Flat networks are designed to reduce the number of routers and switches on a computer network by connecting the devices to a single switch instead of separate switches. Unlike a hierarchical network design, the network is not physically separated using different switches. The topology of a flat network is not segmented or separated into different broadcast areas by using routers.
Wikipedia
The constraints of a flat network are:
- No segmentation of traffic — single broadcast domain.
- Easy and rapid propagation of malicious traffic within the network.
A low-cost layer of security that can be added to a flat network is by leveraging the DNS. Before we look at how to do this, it’s important to reacquaint ourselves with how the DNS works.
Shift of the recursive resolvers
Figure 2 is a simple representation of how the DNS works, from when you type a search term or URL (brainattic.in) into your web browser, to the different routers and servers that search term/URL, then travels to find the site you’re looking for.
I want to draw your attention to the Recursive DNS Server (recursive resolver). As you can see by the number of arrows coming and going from it, it is doing the most heavy lifting in the whole process.
At the very beginning of the Internet, users used to run recursive resolvers on their machines or in their network. This model slowly shifted to network operators (ISPs) offering this as a bundled, free-of-cost offering with their service, and now the model has moved DNS resolution further away from the user with the advent of cloud/quad DNS resolver providers, for example Google Public DNS (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1) and Quad9 (9.9.9.9).
Proximity is important when it comes to the speed of DNS resolution and while each of these cloud/quad DNS resolver services promotes faster DNS resolution, they are, in many cases, a lot further away from users from a round trip metric compared to ISP and local resolvers. They try to make up for this by using IP Anycast and having large caches, however, not even this can compete with the speed of a local resolver.
If you aren’t convinced yet about running your own DNS resolver instead of outsourcing it to a cloud/quad DNS provider, I would urge you to read: Why should I run my own DNS resolver?
Further, if you want to leverage the DNS as a layer of security in your network you need to run a recursive resolver.
How to use the DNS to add a layer of security to your network
DNS Response Policy Zones (RPZ) provide a cost-effective security method similar to a firewall. It allows a nameserver administrator to apply custom policies on top of the global DNS and set alternative routes for queries, in particular, bad domains.
It’s a relatively new method that is still going through the standards process — the latest draft is available here.
A key feature is that it’s vendor-neutral, and so far is supported by BIND, Unbound and PowerDNS Recursor. Admins can set up a RaspberryPi as a recursive resolver with DNS RPZ for the entire network — a particularly useful and low-cost solution for home networks.
Similar to how a generic firewall comprises policies on how it should handle inbound and outbound network traffic, a DNS RPZ comprises policy TRIGGERS and policy ACTIONS that focus on how it should handle various elements in the DNS header (Figure 3).
In the case of RPZ, the TRIGGERS for:
- QNAME matches the domain name in the QNAME field of the question sections in DNS requests and responses.
- Client IP Address matches the IP address of the client sending the DNS requests.
- Response IP address matches the IP addresses in the DNS response.
- NSDNAME matches the nameserver names (NS records) of a domain name in the DNS response.
- NSIP matches the name server IP addresses(A/AAAA) in the DNS response.
Likewise, the:
- NXDOMAIN action response will result in the domain name not resolving.
- PASSTHRU action response will allow exemption of DNS responses and client IP addresses.
- DROP policy action results in discarding the DNS request and response.
- TCP-Only policy action sends a short UDP response requesting the DNS client to try again with TCP. The objective of this action is to mitigate distributed DNS reflection attacks.
- Local Data policy allows any actionable result. For example, for educating the user that the domain name has been rewritten, the DNS client can be redirected to a web page or to a walled garden.
Improve your DNS firewall with intelligence data
A DNS firewall is only as strong as the knowledge of the malicious domains to filter for. Staying up-to-date with this ever-growing list is near impossible for network admins.
Luckily there are many threat intelligence agencies that provide DNS RPZ feeds including free/community ones managed by Spamhaus, URLhaus and StevenBlack.
In the context of the DNS, threat intelligence data can point to indicators of compromise (IOC), suspicious domains, malware (phishing, botnets) and domains having zero reputation.
In Part 2 of this series, I will go into more detail on how to configure an RPZ feed in ISC BIND9.
Adapted from original post with modifications that appeared on Brainattic.
Swapneel Patnekar is a DNS geek, network engineer and researcher with interests in Unix systems, networking and security. He is also an APNIC Community trainer and a RIPE Atlas Ambassador.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.