Securing DNS: a primer

DNS security is a hot topic. That said, there are a lot of misunderstandings around it, and available resources can be further confusing. For example: DNSSEC isn’t short for DNS security as a whole. Both DNS-over-TLS and DNS-over-HTTPS are useful, but carry risks that may outweigh their benefits in certain cases.

To clear the confusion, we thought we’d put together, similarly to our automation series, a guide to help you better understand what DNS security is (and isn’t), what are the best practices for securing your DNS services, and what are the trends that may affect you along the way.

DNS security in a nutshell

A secure DNS is essential. As the core service that governs network routing, DNS is a prime target for malicious actors to exploit.

Yet, DNS security hasn’t been (and still isn’t, sadly) self-evident. Created as a shared resource, DNS protocols are inherently open — but that also means they’re also more vulnerable than, say, secure HTTP traffic.

The lack of proper and widespread DNS security is especially apparent in corporate environments. DNS was invented for what eventually became the internet, and that open approach keeps proving to be opposed to enterprise priorities.

Luckily, there are ways to secure DNS, both in the enterprise and on the open internet.

DNS security: threats and defenses

First, let’s take a look at the most common attack vectors against DNS.

DDoS and other brute force vectors

When you hear DNS security, chances are you’re thinking about defending against the most common threat: brute force.

The simplest way for attackers to bring down your DNS (and with it, your network) is overloading it above capacity. By generating more requests than the DNS can handle, they can force it to become unavailable for legitimate connections. DNS can’t distinguish between faux requests and real ones and handles connections on a ‘first come, first served’ basis.

Brute force attacks came in many flavors. DDoS is the most prominent (or known), but there are also methods such as flood attacks, random subdomain (or nxdomain) attacks, malformed DNS packets, or amplification.

Brute force is simple and kind of stupid. These attack vectors are, while dangerous to the health of the network, carry little threat to valuable data.

Brute force attack vectors can be mitigated through redundancy. By creating backup services, they can step in and share the load or take over entirely until the primary DNS service is available again.

Cache poisoning

More sophisticated attackers may want not just to cause an outage, but also to steal data. Cache poisoning is one of the ways to achieve that, where they take advantage of the cached nature of DNS and redirect legitimate queries to malicious endpoints.

Because DNS is the core protocol that keeps networks running, cache poisoning is dangerous because there’s no other service that can act as a validation mechanism. Simply put, if the DNS says this is where the traffic should go, the traffic will obey.

DNSSEC is the most effective way to deal with this kind of attack, as it validates DNS queries and responses. It can also be used in more restrictive environments. (Unlike DNS-over-TLS or DNS-over-HTTPS, which can create complications for visibility in a corporate setting.)

Tunneling

DNS tunneling is not an attack on DNS itself but can use DNS requests (which are treated differently than other protocols) to carry malicious or illegitimate data, and thereby circumventing firewalls and other security measures.

DNS hijacking and domain theft

Attackers can try and gain access to the domain (through the registrar) or the DNS service itself to modify or destroy it. This can take many forms, but the chief vulnerability is the human element.

Sophisticated authentication and proper access control can mitigate much of these vectors.

Security =/= privacy

Nowadays, when we talk about DNS security, many people often mistake security for privacy. Mozilla and Google work hard to make DNS-over-TLS or DNS-over-HTTPS a standard practice to establish private and secure DNS traffic between clients and resolvers.

While in the case of the internet, this has legitimate ground, in more restrictive corporate environments it obscures the visibility over DNS traffic. Loss of visibility can quickly become a vulnerability, as the network managers for the organization can’t identify the source of malicious activity.

Both DoT and DoH carry valuable methods that can benefit enterprise networks, but auditing their implementation is paramount to keep these networks secure.

Securing your DNS

In our next posts, we’ll take a closer look at each attack vector, and how to identify and mitigate its damage for your organization.

If you have any questions, or there’s a topic we didn’t cover or would like to know more about, let us know. We’ll be happy to dive into it.