DNS Resolution Required can help make the internet safer

DRR can add significantly to the protection provided by DNS firewalls and provide additional protection to systems that do not use DNS firewalls. At the same time, it is both more effective and more flexible than simply blocking all DNS traffic.

There are some limitations to DRR, but in environments where the constraints in question are irrelevant or can be worked around, we think DRR offers an important additional layer of security. We see DRR as particularly valuable in constrained environments, where management access to internet-connected devices is limited (as with the Internet of Things), or where there is a requirement for additional security (as with internet-connected medical devices).

In this first part of our two-part blog post, we discuss the concept of DRR and its relevance. In part two, we discuss the operationalisation of DRR.

DNS blocking and DNS firewalls

DNS blocking is a well-known and widely used technique that protects clients against malicious traffic by blocking domain names that are known to be malicious. DNS servers that implement DNS blocking are referred to as DNS firewalls. They keep track of domain names and IP addresses that are known to host malware or botnet command and control centres on a 'block list', and when a client tries to resolve one of the listed domains, they return an error instead of the resolved address.

Examples of DNS firewalls include public resolver services such as OpenDNS, which allows users to set filter rules, and local DNS resolvers that implement DNS Response Policy Zones (RPZ), such as BIND or Unbound. For instance, Unbound can be configured with an RPZ to prevent the bots in a botnet (e.g. Feederbot) from contacting their command and control domains, thereby disrupting the operation of the botnet and protecting other machines from being infected by the botnet or from becoming victims of botnet-powered DDoS attacks.

The problem: DNS firewalls offer limited protection against malware

The problem with DNS firewalls is that the level of protection they offer against malware is limited: malware can perform its own DNS resolution (e.g. Cutwail), or simply skip DNS resolution completely (e.g. Nugache), or even change the DNS configuration of the system entirely (e.g. DNSChanger). In such scenarios, the malware is not reliant on the DNS resolver set by the system administrator or ISP. DNS firewalls do not provide any protection against such malware, so additional security measures are needed.

Protecting against malware more effectively using DNS Resolution Required

To protect against such malware more effectively, we need to add additional protection to edge networks, with a security function that we have dubbed "DNS Resolution Required" (DRR). In short, a DRR-enabled network makes sure that every connection between a client and a remote service is preceded by a DNS response from one of the network's authorised DNS resolvers, which we define as resolvers configured by the user or network administrator (e.g. an ISP or a corporate network). DRR does that by analysing the DNS traffic on the network. By default, DRR blocks all outgoing traffic from clients to any IP address, except for DNS traffic to authorised DNS resolvers. When it sees a DNS answer from one of those resolvers in response to a DNS request by a client, it dynamically opens the local system's or local network's firewall for the IP address(es) in that answer.

A DRR system is complementary to a DNS firewall. On its own, DRR offers protection against DNS leaks, DNS-changing malware and malware that tries to circumvent the local DNS configuration, for instance to protect itself against intrusion detection based on DNS. But the real value of DRR is when it is used together with a DNS resolver that implements DNS malware blocklists: DNS queries can only be sent to that resolver, and traffic is only allowed if that resolver has returned a valid answer.

Existing solutions

There are existing countermeasures against some of the types of malware mentioned above. For instance, one could simply block all traffic to port 53, except to the configured resolver. Alternatively, one could hijack all DNS traffic on the firewall and redirect it to the authorised resolver. Such arrangements are effective where malware performs its own DNS resolution, but only if it actually uses DNS over port 53 (the traditional approach), and not, say, DNS over HTTPS. They are also not effective against malware that connects to IP addresses directly. DRR is a novel concept that offers protection against all the types of malware mentioned above, especially when used with an up-to-date DNS firewall. The DNS firewall will filter out known malware, while DRR protects against anything that could circumvent use of the DNS firewall.

High-level operation of DNS Resolution Required

Figure 1 illustrates the high-level operation of a DRR system. It continually listens for any DNS answers sent from the configured resolvers to clients on the network. If a client performs a DNS lookup and one of the authorised DNS resolvers returns an answer containing IP addresses, the DRR system allows traffic to those remote IP addresses by instructing the firewalls accordingly. When the DNS time to live (TTL) expires, it blocks those IP addresses again.

Figure 1: DRR sequence diagram

The result is that a client on the network cannot contact a remote IP address until the IP address has appeared in a DNS answer. So, if the client is running malware and uses a non-authorised resolver, or uses remote IP addresses directly, the traffic will be blocked on the firewall, and the malware is effectively stopped from causing any more harm.

DRR requirements and limitations

In order for a DRR system to work, it must be able to see the DNS traffic, specifically the DNS answers from the configured resolver. In its most basic form, that requires the use of standard unencrypted DNS over port 53. Using DNS over HTTPS (DoH) or DNS over TLS (DoT) would result in connection failures, since DRR would not open the firewall for the resolved domain names. In order to work with DoH or DoT, the DRR system would either need to be a DNS proxy, or would need an out-of-band connection to the resolver in order to retrieve the necessary information.

Of course, the DRR system also needs to interact with the firewall. It needs to be either integrated into the firewall software itself, or configured to send the firewall the correct commands to open and close resolved domain names and IP addresses. A generalised DRR system would therefore need to have a modular design, so that it can work with multiple firewall implementations.

Since traffic is allowed only from and to IP addresses that have been observed in DNS responses, DRR has the limitation that it will also block any traffic that does not use DNS to find IP addresses. For example, peer-to-peer software and a number of voice-over-IP (VoIP) solutions communicate IP addresses within their own protocols, and those will – by default – be blocked by a DRR system.

Next blog

In this blog, we described the general concept of DRR. Its limitations could be an issue in a use case where VoIP, peer-to-peer or a similar protocol is used. However, we think the advantages of DRR could outweigh those limitations, especially in more constrained environments, or environments with additional security requirements. In such scenarios, we think DRR could significantly improve the security of the network, especially if combined with a DNS firewall.

In the next article, we will discuss potential deployment scenarios and our initial DRR system prototypes.