Operationalising DNS Resolution Required for the Internet of Things

Deployment in a typical network with IoT devices

In a typical home environment with IoT devices, we can filter traffic on the router, because all the internet traffic to and from the IoT devices will go via the router and its firewall. Figure 1 shows a very common setup. In this scenario, the DNS resolver is located outside the local network. The resolver could be operated by the ISP, or a DNS service provider such as Quad9 or Cloudflare.

If the hosts send their queries directly to an external DNS resolver using standard plain-text DNS, it is possible to implement DRR by catching the DNS traffic on the router. In that scenario, DRR will protect any device in the local network, and the devices themselves will not need to be modified or updated.

Figure 1: A common setup with a remote resolver.

Implementing and evaluating a DRR prototype

We have developed an early prototype of DRR to validate the DRR concept in the scenario described above. It runs on the router and works by intercepting DNS traffic while updating the local firewall rules.

More specifically, the implementation intercepts DNS traffic, passes it to the userland daemon of the prototype, updates the firewall's configuration, and only then sends the DNS answer to the client.

This means that DNS responses are delayed for the time that it takes to update the firewall rules. An alternative approach would have been to pass on the DNS response to the client immediately, and process the firewall update in the background. That approach, however, could cause issues: if the client application tries to contact the remote IP address before the firewall has finished updating, its traffic would still be blocked.

The current implementation of our prototype supports only iptables with the nfqueue module. It is possible to provide similar functionality for OpenBSD's Packet Filter (PF) through divert(4), but that was not implemented in this prototype.

We evaluated this prototype by performing our daily activities while running the application on our workstation in a home network environment. While this is not the real target scenario we have in mind for DRR, it does give a good impression of the effects of using DRR on a home network.

When browsing the web, we did not observe any failed connections. However, browsing the web using the DRR prototype was noticeably slower than browsing when DRR wasn't enabled. That is not surprising, given that every DNS answer was intercepted and processed before being delivered to the client that requested it. That slightly slows every connection for which a DNS lookup is required and the relevant data is not cached locally. Since loading a web page can involve numerous DNS queries, the slowdown is significant when visiting a website for the first time. However, in situations where a client only needs to contact a few remote services, as in an IoT scenario, the delay does not have a noticeable effect. One potential way to improve the delay is to use a system like ipset for more efficient updates.

The prototype was found to have another implementation-related problem, which could definitely be solved by better implementation. The prototype is written in Python and uses nfqueue to delay the DNS packets. The Python-nfqueue wrapper is not readily available on many routers, which makes the prototype hard to deploy on most networks. Running it on our workstations was easy, but deploying it on our OpenWRT router was not as straightforward. Implementation in a more low-level language, or in a language where nfqueue libraries are directly available, would solve that issue.

Traffic rule validity periods

The firewall rules that allow traffic to certain IP addresses should not remain effective indefinitely. Therefore, a DRR implementation needs a mechanism for rescinding the rules at some point in time. One possibility that springs to mind is to use the Time to Live (TTL) of a DNS response as the validity period for the associated traffic rule. However, that could lead to problems with connections that remain open for prolonged periods, as no fresh DNS query is sent in those cases.

We currently see two possible solutions for that issue: (1) tracking open connections, and (2) always allowing TCP packets that are not connection initiators (i.e. blocking TCP SYN packets and all non-TCP packets unless they are on the allowed list). Let's look at each option in more detail.

Tracking traffic directly. If a connection remains open longer than the TTL of the DNS answer, we could simply allow traffic to the destination to continue as long as the connection remains open. If there hasn't been any traffic for some time, and the DNS TTL has expired, the address could be removed from the allowed list. However, that would mean the DRR implementation needing to keep track of connection states, which is a feature better left to the firewall itself.

The second option is to always allow TCP traffic that doesn't initiate a connection. TCP connections are initiated using a handshake, so in theory the default block rule could make an exception for any traffic that is not part of this handshake (but is a continuation of an established connection). Stateful firewalls already keep track of such information, and either they already let packets exchanged via established connections pass, or it is relatively easy to configure them to do so. This second approach has the advantage that a DRR implementation would not need to keep track of current connection states.

Our prototype uses this second approach to make sure existing data streams are not interrupted when the TTL of a DNS answer expires.

Alternative deployment scenarios

In this section, we discuss two alternatives to the deployment scenario we had in mind when developing our first DRR prototype. The deployment scenarios differ mainly in terms of where the DNS resolver is located, which influences how and where DRR can be deployed. We will call the original scenario described earlier, with a remote resolver, Scenario A.

In alternative Scenario B, the router itself runs a resolver. Figure 2 shows the setup in that scenario. The router acts as a resolver, and filtering rules can be based on the responses sent to the stub resolvers. The best place to implement DRR in this scenario would be on the router as well. In fact, the same setup could be used as in scenario A.

However, in this scenario, DRR could also be implemented as an extension to the resolver software itself. In that case, the DRR implementation would have access to all the necessary DNS information without having to capture the DNS packets. The big advantage of such an approach is that the DRR implementation is not dependent on plain-text DNS traffic, and DRR can still function when the DNS traffic is encrypted with for instance DNS over HTTPS (DoH) or DNS over TLS (DoT). Whereas, in scenario A, DRR doesn't work with encrypted traffic.

Figure 2: Scenario B with a local resolver.

In the third scenario, Scenario C, there is a forwarding resolver that runs on the router. Scenario C is therefore essentially a combination of Scenario A and Scenario B, as shown in Figure 3. In terms of potential filtering locations, this scenario is the same as scenario B; the filter rules can be based on the results from the forwarding resolver, and DRR can be implemented as an extension to that forwarding resolver.

Figure 3: Scenario C with a forwarding resolver.

So far, we have discussed filtering on the router or resolver. An alternative approach is filtering on the local hosts, with the hosts' stub resolvers doing the filtering. That has the advantage of being viable in any scenario regardless of the network setup, but makes the hosts themselves responsible for the filtering. That isn't always possible, for instance with IoT devices that have limited capacity for additional processing, or if there is no firewall functionality on the system at all. Another disadvantage is that it still leaves the host vulnerable to malicious software that alters system-wide DNS settings, since the malware could also alter the DRR settings.

Applications of DRR beyond IoT

When considering the DRR concept and our prototype, we primarily had in mind a network with constrained IoT devices. Nevertheless, the DRR concept can also be very useful outside that IoT home network application scenario. However, the use of DRR beyond the IoT is subject to some caveats and limitations. Some of those were mentioned in our first article on this topic. Recent experiments have revealed a few more, so the list has been extended. Some of the limitations are a result of the prototype design, and can be resolved by better implementation. Others are inherent to the DRR concept, and could in certain circumstances even be seen as features.

The first limitation is speed: DNS responses need to be delayed until the firewall rules have been updated, so that clients do not try to establish connections before the firewall has been updated. The impact of such a delay depends largely on how quickly the firewall rules are updated and how efficient the DRR implementation itself is. However, we noticed in our experiments that the delay is noticeable in scenarios where a user is directly involved, such as browsing the web. How much of an issue this would be in practice is hard to say on the basis of (inefficient) prototypes. Such a delay is primarily an issue when browsing the web, as websites tend to need a lot of DNS queries, and even delays of a few hundred milliseconds are noticeable by users. For IoT devices, however, such delays should not be much of a problem.

Another limitation relates to traffic to locally configured IP addresses, such as those in configuration files or in the system's hosts file. Such addresses are not resolved with DNS and will therefore be blocked by DRR. A DRR system would need some way of configuring 'trusted' addresses, and allowing them even if there is no related DNS lookup traffic. That would mainly be a matter of adding configuration options.

A partially related but more serious limitation is that protocols that exchange IP addresses in-band will fail. Such exchanges skip DNS resolution, so the IP addresses that are exchanged and subsequently used are not known to the DRR system, and therefore not allowed by the firewall. Examples of such protocols include SIP, BitTorrent and, more generally, many voice-over-IP (VoIP) and peer-to-peer communication protocols. There is no easy workaround for this, as the IP addresses in question cannot be known beforehand. However, since such protocols often run into issues when used with network address translation (NAT), and have implemented workarounds for that, a similar solution might be possible for DRR as well. Perhaps a DRR system could hook into a STUN solution or similar helper functionality, but we have not researched that possibility yet.

A fourth limitation depends on the way DRR is implemented: as flagged up earlier, a general-use implementation, such as our prototype, uses captured plain-text DNS packets. A setup like that will obviously run into problems if some form of encrypted DNS is used, such as DNS over HTTPS (DoH) or DNS over TLS (DoT). In some ways, that could be an advantage: malware would also be unable to use DoH or DoT in order to hide its DNS use. However, all legitimate encrypted DNS applications would fail as well. The only real workaround for this would be to have a secure channel to the actual resolver, and a protocol for exchanging IP addresses and TTLs. One could imagine the resolver implementing DRR itself, with a small local agent to update firewall rules.

Conclusions and follow-up

Our brief evaluation of our prototype shows that DRR can indeed work. While it has some limitations that might make it impractical for general-purpose PC use (it is incompatible with VoIP and peer-to-peer protocols, for example), we think it could add significant network security in more constrained scenarios.

For example, DRR could be used to protect IoT devices in a home network only or be used in a network where there are high security requirements, as in health care.

We are currently considering writing a 'real' implementation that addresses the main issues of the second prototype (namely speed and deployability). If you are interested in such a system, let us know!

Of course, other feedback and questions are welcome, so reach out!

We have not published the prototype source code, but if you are interested in it, it's available on request.