DNS over HTTPS (DoH) - DNS over TLS (DoT)
I wrote about DNS Security weeks ago because there are increasingly remote users working outside the protected walls and companies want to increase the security of their activities and resources. The DNS-layer security should be the first line of defense against threats because DNS resolution is the first step in Internet access. Some web browsers are already relying on DoH (DNS over HTTPS) for their own IP resolution. But using DoH with an untrusted public DNS service risks misuse of browsing data and reveals applications being utilized. In order to better protect remote workers, companies should therefore instead consider extending their private DNS recursive service and manage the DoH themselves.
On the one hand, if you are going to install a DNS over HTTPS (DoH) infrastructure, you’ll need to configure a proxy farm to take HTTPS requests and sending it to traditional DNS servers. F5 BIG-IP can work as a proxy farm to transpose the data from HTTPS requests and translate into a traditional DNS request. Thanks to iRulesLX engine based on Node.js, BIG-IP can handle DoH translations. DoH requests either arrive at the BIG-IP in an HTTPS POST with a binary payload or a base64url-encoded GET request parameter. These requests are translated from HTTPS to DNS easily by F5 BIG-IP.
On the other hand, if you are going to deploy a DNS over TLS (DoT) infrastructure, you’ll also need to configure a proxy farm to take TLS requests and sending it to traditional DNS servers. BIG-IP can also work as a proxy farm to transpose the data from TLS requests and translate into a traditional DNS request. However, DoT-to-DNS configuration is easier than DoH-to-DNS configuration because proxying DoT queries to traditional DNS only require a classic BIG-IP high-performance SSL offloading profile and no iRule is needed.
These infrastructures are not difficult to configure but if you don’t know how to do it, iApps can help you. There is already a DNS over HTTP iApp which creates an iRule to perform resolution of DoH traffic. Firstly, you have to create a pool containing DNS resolvers. Secondly, install the iApp as a template. Thirdly, create the application service with the iApp. Fourthly, create a virtual server listening on port 443 with TCP, HTTP and Client SSL profile. Finally, test the deployment.
Testing the deployment is really simple because most browsers support DoH. For instance, Firefox can be used as a DoH client. It is configured in the about:config page. Firstly, we set network.trr.uri to our custom virtual server URL. Secondly, we should also enable network.trr.useGET as it’s a bit faster than using POST. Thirdly, we set network.trr.mode to 3, which means we want Firefox to only use DoH. Finally, the network.dns.skipTRR-when-parental-control-enabled disables Firefox’s feature that disables DoH when parental control via DNS is sensed on the network.
To sum up, proxying DoH and DoT queries to traditional DNS is easy to configure and test with a BIG-IP proxy farm. It’s up to you if you want to protect your remote workers and extend your private DNS recursive service.
Have a nice day!! Would you like to deploy a DoH or DoT infrastructure?