Introduction

DNS is a critical service for almost every network. Because it translates human friendly names to IP addresses, attackers often target DNS to redirect users, steal data, or take services offline. DNS security is about protecting the DNS infrastructure, the integrity of DNS data, and the privacy of DNS queries. In this chapter you will see the main risks and the common protections used today.

Why DNS Is a High-Value Target

Every time you visit a website or connect to many online services, a DNS lookup likely happens first. If an attacker can control or trick DNS, they can send you to a fake server without changing anything on your device or in your browser. This makes DNS a very attractive point of attack.

DNS is also usually based on UDP, and many resolvers are exposed on the internet. This combination has historically made DNS both easy to reach and easy to abuse, for example in amplification attacks that can be used for distributed denial of service.

Common DNS Threats

Several typical attack types target DNS. You will see the names of these attacks in practice and in security references, so it is useful to know roughly what they mean and how they relate to DNS.

DNS Spoofing and Cache Poisoning

DNS spoofing is when an attacker provides fake DNS answers in place of the real ones. If a resolver accepts a fake answer and stores it, its cache becomes poisoned. After that, every user that relies on that resolver may receive the fake IP address.

Resolvers usually match responses to queries using fields such as transaction ID and source port. If an attacker can predict or influence these values, they might send forged responses that appear legitimate.

The impact can be serious. Users may think they are on a trusted website, while actually connecting to a malicious server. Encryption at higher layers such as HTTPS can reduce the damage, but if users ignore certificate warnings, spoofing can still succeed.

DNS Hijacking

DNS hijacking is when DNS queries are redirected to a resolver controlled by an attacker or by some intermediate party. This can happen on a compromised router, a malware infected device, or a malicious Wi Fi hotspot.

Instead of poisoning a cache, hijacking changes where the queries go in the first place. In some cases, ISPs or captive portals also manipulate DNS for policy or advertising reasons, which is a milder form but technically still a type of hijack.

DNS Tunneling

DNS tunneling is the use of DNS queries and responses to carry other data. An attacker might encode commands or stolen data inside the domain names of queries. The responses can contain encoded instructions.

Because DNS often crosses security boundaries and firewalls, tunneling can become a method of data exfiltration or covert communication. It usually looks like unusual, long, or very frequent queries to obscure domains.

DNS Amplification and DDoS

DNS can be abused to amplify traffic in a denial of service attack. The attacker sends small DNS queries to open resolvers, but forges the source IP so that responses go to the victim. Because one small query can generate a much larger response, this amplifies the amount of traffic the victim receives.

Open resolvers that respond to queries from anywhere on the internet are a key enabler of amplification. High volume reflection of DNS responses can overwhelm networks or servers and cause outages.

Protecting DNS Integrity: DNSSEC

DNS Security Extensions, or DNSSEC, add cryptographic verification to DNS records. DNSSEC does not keep your queries private, but it gives you a way to verify that the answers you get are authentic and have not been tampered with.

Basic Idea of DNSSEC

With DNSSEC, each DNS zone can sign its records using a private key. The corresponding public key is published in DNS, so resolvers can use it to verify signatures.

When a resolver that supports DNSSEC asks for a record, it can also receive a signature. The resolver then checks that the signature matches the data using the stored public keys. If everything checks out, the data is considered valid.

Chain of Trust

To avoid manually trusting thousands of individual zones, DNSSEC uses a chain of trust that follows the DNS hierarchy.

At the top, the root zone has a key that is trusted by design. The root then signs information about the keys of top level domains. Each top level domain signs the keys of second level domains, and so on. This creates a sequence where each level vouches for the next.

If any part of this chain is broken, the resolver will consider the data insecure or invalid. This prevents an attacker from easily inserting fake keys for a domain without also compromising its parent.

Key Types in DNSSEC

There are usually two main keys in a DNSSEC protected zone.

The zone signing key, or ZSK, is used to sign the zone’s records. The key signing key, or KSK, is used to sign the DNSKEY record that contains the public keys. The KSK connects the zone to its parent in the chain of trust.

Managing these keys, rotating them periodically, and keeping the private parts protected are all important operational tasks. A lost or mismanaged key can cause DNSSEC validation failures and effectively take a domain offline for validating clients.

Recursive Resolvers and Security Policies

Recursive resolvers, often run by ISPs or organizations, are central to DNS security because they cache and validate answers for many users.

DNSSEC Validation

A validating resolver will check DNSSEC signatures when available. If validation fails, it treats the response as bogus and does not provide it to clients. From the user’s perspective, this may look like a name resolution failure.

Resolvers can operate in different modes. Some enforce validation strictly and fail on errors. Others may fall back to accepting unsigned data or skip validation entirely. The exact behavior depends on configuration and policy.

Response Policy Zones

Some resolvers support response policy zones, often called RPZ. These allow administrators to define custom rules about which domain names to block, redirect, or alter.

For example, an organization might subscribe to a threat feed that contains known malicious domains. The resolver can then return a safe address, like an internal warning page, instead of the real IP. This adds a layer of protection against phishing or malware that relies on DNS names.

Transport Security for DNS: DoT and DoH

While DNSSEC protects the authenticity of DNS data, it does not hide queries from observers. To address privacy and certain types of manipulation, new protocols protect DNS transport itself.

DNS over TLS (DoT)

DNS over TLS wraps DNS queries inside a TLS encrypted connection. It uses a specific port and behaves in a similar way to HTTPS from a security perspective, but is dedicated to DNS.

With DoT, an on path attacker cannot read the content of queries or responses, and cannot modify them without detection. This defends against local eavesdropping and simple hijacking techniques on untrusted networks.

DNS over HTTPS (DoH)

DNS over HTTPS carries DNS traffic inside regular HTTPS. This means DNS looks like normal web traffic on port 443. From a security perspective, it provides similar encryption and integrity to DoT.

Because DoH shares the same port as web browsing, it can sometimes bypass simple network controls that try to filter or log DNS separately. This is both a benefit and a challenge, depending on whether you look at it from the privacy side or the network management side.

Comparing Traditional DNS, DoT, and DoH

The following table summarizes the main differences.

DNS and Access Control

DNS is also involved in several mechanisms that control or guide access, particularly through specific record types and resolvers.

DNS Based Blocking and Filtering

Organizations or home routers often use DNS as a simple content filter. If a domain is in a block list, the resolver might return no answer, a special address, or an internal warning page. This is not absolute security, because attackers can use direct IP addresses or alternate DNS servers, but it is a practical first layer.

Parental control features on home networks or security features in public Wi Fi systems are frequently implemented this way. It is easy to deploy and hides complexity from end users.

DNS in Email Security

Some important email security features rely on DNS records. For example, mechanisms that help prevent spoofed sender addresses publish policies in DNS. Mail servers then read these records when deciding whether to trust an incoming message.

Although the exact policy formats are outside the focus of this chapter, it is important to understand that DNS is not only used for address lookups, but also as a distribution method for security related information.

Operational Best Practices for DNS Security

Beyond protocols and cryptography, secure DNS depends heavily on good operational choices.

Securing Authoritative Servers

Authoritative servers hold the original records for domains. They should not be exposed as open resolvers that answer recursive queries for arbitrary names. Mixing authoritative and open recursive roles on the same server increases risk.

Access to DNS zone files and management interfaces should be tightly controlled. Changes to critical zones, such as those hosting important business services, usually follow change management processes and are often logged and reviewed.

Avoiding Open Resolvers

An open resolver is one that responds to recursive queries from anywhere on the internet. Open resolvers are commonly abused in amplification attacks and can also serve as a vector for cache poisoning against many users.

Resolvers intended for internal clients should restrict access by source IP or by network. Public resolvers that accept queries from anyone must be correctly secured and monitored, because they become part of the global infrastructure.

Logging and Monitoring

DNS logs give insight into which queries are common, which domains are suddenly popular, and where errors occur. Unusual patterns, such as very high query rates for random looking names or domains that are newly registered, can signal an ongoing attack or malware activity.

Monitoring latency and error rates for DNS responses is also important. If DNS becomes slow or unreliable, users often perceive all network services as broken.

Limitations and Trade-offs

Every DNS security measure involves trade offs in complexity, performance, or privacy.

DNSSEC adds larger responses and more processing. Validating resolvers must handle signatures, and failures can cause confusing outages if not understood by operations staff.

Encrypted DNS through DoT or DoH protects privacy, but can make centralized security controls more difficult, because intermediate devices cannot easily inspect queries. This sometimes leads to tension between user privacy goals and organizational visibility needs.

DNS based blocking and filtering is simple and cheap, but it is not a complete security solution. Attackers can use numeric IP addresses, custom resolvers, or encrypted tunnels to bypass filters. It is best used as one layer among many.

Summary

DNS security focuses on keeping DNS reliable, authentic, and as private as necessary. Threats such as spoofing, cache poisoning, hijacking, tunneling, and amplification attacks show how central DNS is to both attackers and defenders.

Mechanisms like DNSSEC protect the integrity of DNS data through signatures and a chain of trust. Transport level protections such as DNS over TLS and DNS over HTTPS protect queries from eavesdropping and manipulation in transit. Operational practices, such as avoiding open resolvers, securing authoritative servers, and monitoring logs, complete the picture.

Together, these measures create a more trustworthy name resolution environment, which is essential for the secure operation of modern networks and applications.

Views: 74