Securing Your DNS

When the Domain Name System (DNS) was created in 1983 I imagine its creator Paul Mockapetris and his team had no idea that nearly 40 years later our interconnected world would be so reliant on the very simple, but critical, DNS network service.

I have a love-hate relationship with DNS. I love all of the memes I see about how “It’s always DNS”, but I hate that it’s also true—I always forget to check that DNS is working correctly when troubleshooting network issues! But let’s leave troubleshooting DNS issues for a later date.

Today, let’s focus on securing your DNS. It’s increasingly becoming a topic of conversation in network security, so a number of initiatives are underway to evolve DNS and improve the security of this critical service. Let’s take a look at some different DNS security concepts and what they mean for the future of networking.

Why does security matter?

Whitepapers on using DNS to siphon data have been around for years, including pieces from InfoBlox and Akamai. Recently, siphoning data over DNS has garnered media attention due to a major supply chain attack that affected a number of network and security vendors, along with a long list of private companies and government agencies.

This renewed interest in DNS security is a great thing—it’s going to make each and every network more secure as more companies implement measures to protect their DNS infrastructure, and more vendors improve solutions for customers of all sizes. A rising tide lifts all boats, right?

As we dive into the different concepts on securing your DNS, let’s keep the security triad of confidentiality, availability, and integrity (CIA) in mind. As we’ll see, when we discuss these different security concepts, they each relate to not only a different aspect of the triad but to each other as well. Let’s have a look.

DNSSEC

Domain Name System Security Extensions (DNSSEC) were introduced by the IETF over 20 years ago as an initial effort to make DNS more secure. One of the main benefits of DNSSEC is that it provides a better trust framework for DNS data.

The role DNSSEC plays is to ensure that the data comes from an authoritative source and that the data received hasn’t been tampered with since it was originally created. This specifically addresses the integrity component of the CIA triad.

Simply speaking, if a request came in for subdomain.example.com, DNSSEC provides the framework to ensure that the IP address that subdomain.example.com resolves to comes from the owner or administrator of example.com and hasn’t been altered since it was created.

DNS over TLS (DoT), and DNS over HTTPS (DoH)

Where DNSSEC addresses the integrity of the data, DoT and DoH have been developed to address the confidentiality of DNS traffic.

DNS traffic was not originally designed to be encrypted, so these two sister concepts enable the encryption of DNS traffic so that DNS requests can’t be read as they traverse the network. Cloudflare has put together this awesome breakdown and step-by-step explanation of encrypting DNS that includes an example of a packet capture of a DNS request in clear text, and the problems that it causes.

While there’s a lot in common between DoT and DoH, they’re not exactly the same. DNS over TLS is defined in IETF standard RFC 7858, and while I’m sure you’d love to read the technical documentation, the one key difference is this: DNS over TLS specifies TCP port 853 as the defined port for DoT traffic (very similar to DNS’s port 53).

Shortly after specifying the DoT protocol, unfortunately, experts realized that introducing a new DNS port may cause connectivity issues if port 853 was blocked. As well, many of the systems that need to use DNS, like your web browser, are already using TLS to encrypt traffic on a different port (443) and have APIs that can encrypt DNS traffic as well. With this in mind, DNS over HTTPS was introduced in a new IETF standard, RFC 8484.

One of the downsides of DoH is that with DNS traffic tunneled over HTTPS, DNS requests can fly under the radar and simply leave the network as any other HTTPS traffic, leaving network administrators with a possible visibility gap into DNS requests. While this shouldn’t prevent an organization from embracing DoH, it’s something to think about when evaluating alternatives.

DoT and DoH—which should you use?

In some cases, you may already be using DNS over HTTPS. Many browsers, such as FireFox and Chrome, have been rolling out DoH since 2019. You can take a quick look in your browser to see if it’s securing your DNS by going through the settings.

If you’re still not sure, the NSA recently recommended that all organizations adopt DoH for enterprise DNS implementations. The NSA actually recommends all DNS traffic be funneled through your enterprise DNS infrastructure, encrypted both internally and externally. DoH from the web browser vendors currently gives you the option to direct your DNS traffic to a third party. I suspect it won’t be long until DoH organization-wide is common practice for organizations of all sizes.

What can you do right now to make your DNS infrastructure more secure?

You might be thinking, “Steve, I’m not quite ready for DoH, DoT, or DNSSEC, but I can’t leave the office today without improving my DNS security!” So, what can we do right now to improve your security posture?

Most importantly, put controls on outbound DNS requests in your network.

It’s fairly common practice to set up a firewall policy that permits the majority of LAN to WAN traffic, without much control. In doing this, you’re effectively allowing all devices in your network to use whatever DNS servers they want along with other generally “bad” things. While your DHCP server may be specifying your internal DNS server for your users to leverage, users are free to set their DNS server to whatever they want.

There are lots of great options your users could use to secure your DNS, like CloudFlare’s 1.1.1.1 public DNS resolver (or the recently launched CIRA Canadian Shield for those in Canada). Keep in mind, if your users do use these services, you’ll lose visibility and logging of their DNS requests. And if you’re using any DNS security tools like Cisco Umbrella or DNS Filter, bypassing these security tools is as simple as changing the DNS server on an endpoint.

So do this one thing today toward securing your DNS: restrict outbound DNS traffic. Whitelist only outbound requests from your DNS server or whitelist only requests going to your approved DNS security tool. Block everything else heading outbound on port 53. While it won’t stop a DNS exfiltration attack, you’ll at least have visibility and a log of DNS requests from your network.

—

Still have questions on securing your DNS? I’d love to hear them – Drop them in the comments, or connect with me on LinkedIn!