DNS Security At The Edge

In my third installment of this series about DNS security, I am focusing on how we can audit all DNS requests made in our network.  In the second installment, I focused on secure communications between DNS servers. And I highlighted the value of DNSSEC and the potential of DNS-Over-HTTPS (DOH). I outlined some of the changes that we’ve made – including the deployment of DNSMasqd on our router and on our Pi-hole. Today, I will focus upon ensuring that end-to-end auditing is possible – if desired.

As noted previously, we upgraded our router (i.e., a Netgear R8000 X6) from stock firmware to DD-WRT. We did this for numerous reasons. Chief among these reasons was the ability to set up an OpenVPN tunnel from our network out to our VPN providers’ VPN endpoints. But a close second was a desire to run DNSMasqd on the router. Since we haven’t chosen to move DHCP functions to the Pi, we wanted a DHCP service that would have better capabilities. More importantly, we wanted to update DHCP option #6 so that we could control what name servers our clients would use. In our case, we knew that all clients would use our Pi-hole as their name server.

After we realized that DNS options on the admin panel didn’t apply to DHCP clients, we figured out how to set name servers for all of our DHCP clients. Once done, all clients began direct interaction with the Pi-hole. [They had previously used the router as a DNS proxy to our Pi-hole system.]

But as is often the case, there were unforeseen consequences. Specifically, reverse lookups (for static address) failed. This meant that DNS security would suffer because we couldn’t correlate elements across the entire request chain. We could have moved dhcpd to the Pi-hole. But we wanted to have a DNS fall-back – just in case the Pi-hole failed. So we changed our processes for assigning static addresses. Now, we will add them to the router as well as to the /etc/hosts file on the Pi-hole. Once implemented, we had clear visibility between request origination and request fulfillment. [Note: We will probably turn this off as it defeats the very anonymity that we are trying to establish. But that is for another day.]

So what’s left?  In the first two articles, we set up DNS authentication wherever possible. We also established DNS payload encryption – using DNS-Over-HTTPS. Now we have a means of authenticating DNS server communications. And we have an encrypted payload. But there is one last need: we have to limit the ‘data at rest’ stored by each DNS resolver.

Consider this: If we validate our connection to Google, and we encrypt the traffic between us, then Google can still look at all of the DNS queries that it receives from us. That is fine if you trust your principal DNS resolver. But what if you don’t? A more secure process would be to ask for name resolution directly, rather than through a trusted (or un-trusted) intermediary. In my next article, I will discuss how we implemented a recursive DNS resolver alongside our Pi-hole. Specifically, I’ll talk about using Unbound to limit the amount of ‘data at rest’ that we leave with any single DNS service.