We Need to Encrypt DNS: Here’s Another Compelling Reason Why

History of DNS

In 1983, when the Domain Name System, or DNS was invented, the world was a very different place. I had a full head of hair and a thick mustache, which at the time seemed like the height of coolness. But I digress.

In 1986, when the internet was just three years old, the Internet Engineering Task Force (IETF) adopted DNS as one of its foundational standards. We had to wait another three years until the World Wide Web, as it was quaintly known back then, was launched.

DNS is absolutely critical to the operation of the internet and web — every time you do something online, DNS is involved. Whether it's sending an email, online shopping, or accessing a cloud database for work, DNS sits silently in the background translating all those “www” requests to the physical addresses of the servers where these resources are located. For example, without DNS, you would need to know the physical IP address of your email server.

Before I get all misty-eyed and sentimental about information superhighways, dial-up modems, and Netscape Navigator, DNS as it was created in RFC 1034 and RFC 1035 had one fundamental flaw: DNS packets are sent unencrypted across the internet. That means anyone with a basic knowledge of networking can view and potentially manipulate DNS traffic.  

That was okay back in the 1980s and 90s, but the online world has changed dramatically since then. The industry wised up to the dangers of bad actors intercepting and manipulating IP traffic, and nowadays more than three quarters of that traffic is encrypted as HTTPS. Even when Domain Name System Security Extensions (DNSSEC) was introduced in 1999, it focused on providing integrity for responses (preventing an attacker from spoofing responses) and did nothing to encrypt DNS lookups.

Industry response

However, the industry has been somewhat slower to start moving toward encrypting DNS traffic. In particular, the standards are still under development for configuring clients to encrypt DNS, and this is not an easy problem due to challenges with trust bootstrapping. As a result, the vast majority of client-to-resolver DNS traffic remains unencrypted.

I was reminded of just how risky this is when I read a really interesting new academic security research paper titled “On the Vulnerability of Anti-Malware Solutions to DNS Attacks,” which was co-authored by Akamai security researcher Asaf Nadler.

The focus of the paper was on how endpoint antivirus solutions use DNS to try and keep up-to-date with the fast-moving pace of threats. In essence, when an endpoint AV solution scans a file that is not marked good or bad by comparing it against its signature database, it sends a hash of the file to a cloud database using the DNS protocol to see if that file has been marked as malicious. This approach means that the endpoint AV has more up-to-date protection against newly discovered threats and before the on-device signature database has been updated.

The paper highlights how this approach of using unencrypted DNS as a communication channel could be used for malicious purposes. For example, an attacker could, in theory, deliver a malicious file to an endpoint that they know is not in the AV’s signature database. When the endpoint AV sends a request to the cloud database, the attacker can simply intercept that request and respond with a “this content is safe” message.

DNS encryption is necessary

Furthermore, with an increasingly mobile workforce and a shift to Zero Trust models that don't rely on VPNs, untrusted local networks can see what users are doing. As an enterprise IT department, do you really want the network administrators (or other users in a coffee shop or coworking space) to see all of the potentially sensitive data that may be exposed via DNS lookups?  

Again, this underscores the need to start moving toward encrypting DNS traffic, just as we have with HTTP traffic. At the moment, there are two standards that have been proposed: DNS over HTTPS (DoH) and DNS over TLS (or DoT). These have been around for some time, and each is applicable in different scenarios. DoH and DoT are focused on the first hop between the client device and the recursive DNS resolver. Much of the complexity involved centers on how DoH and DoT get configured and provisioned. For example, enterprise networks don't want their clients to start using off-network encrypted DNS servers operated by untrusted third parties.

Find out more

One way to accelerate your adoption of DoH and/or DoT is to move to a cloud-based DNS resolver. Akamai’s cloud-based secure web gateway, Secure Internet Access Enterprise, supports DoH and DoT, and for good measure you can also enforce DNSSEC. To find out more, and to sign up for a free 60-day trial, visit https://www.akamai.com/products/secure-internet-access.