# DNS security explained: Attacks, DNSSEC, and secure DNS controls

DNS was designed primarily for distributed naming and reliability, not the security requirements of today's internet. When the Domain Name System was introduced in the 1980s, it did not include mechanisms to cryptographically authenticate DNS data or encrypt DNS queries. As a result, traditional DNS does not, by itself, verify that a response came from an authoritative source or protect queries from being monitored or modified in transit.

These limitations make DNS a valuable target for attackers. Because DNS helps determine where network connections are directed, manipulating DNS can redirect users to malicious infrastructure, enable phishing and malware delivery, disrupt services, and support data exfiltration.

Understanding how DNS attacks work provides the foundation for understanding the security controls used to protect DNS, including DNSSEC, secure DNS transport, access controls, monitoring, and resilient DNS infrastructure.

## DNS cache poisoning and the Kaminsky attack

DNS cache poisoning is an attack that causes a recursive resolver to store false DNS records in its cache. Once poisoned, the resolver can return the forged record to clients that query it, potentially until the cached record expires or is replaced.

Unlike network-path DNS spoofing, where an attacker intercepts and modifies DNS traffic in transit, an off-path cache-poisoning attack does not require the attacker to control the network path between the client and the resolver. Instead, the attacker attempts to make the resolver accept a forged response as the answer to an outstanding query.

### How cache poisoning works

When a recursive resolver sends a DNS query to an authoritative server, it needs to determine that the response belongs to that specific outstanding query. Traditional DNS uses a 16-bit transaction ID (TXID) as part of this matching process. Resolvers can also randomize the source port used for outgoing queries, adding another source of unpredictability.

An attacker attempting to poison a resolver's cache can trigger a query for a target domain and then send a many forged responses, each using a different transaction ID and, where relevant, targeting different possible source ports. The attacker is trying to make a forged response arrive with the parameters the resolver expects before the legitimate response does. If the forged response is accepted, the resolver can cache the false DNS data.

Early DNS implementations had weaker randomization of transaction IDs and source ports, making it easier for attackers to predict or guess the values needed to win this race. A 16-bit TXID provides only 65,536 possible values, so relying on the transaction ID alone leaves relatively little entropy for preventing forged responses.

### The Kaminsky attack (2008)

In 2008, security researcher Dan Kaminsky disclosed a significantly more effective technique for DNS cache poisoning. Instead of repeatedly targeting the same DNS record, the technique triggered resolution requests for a series of random, nonexistent subdomains of the target domain, such as random1.target.com and random2.target.com.

Each request caused the resolver to perform a fresh lookup, giving the attacker repeated opportunities to race a forged response against the legitimate authoritative response.

The forged response could include malicious delegation information in its additional section, claiming that the authoritative nameserver for target.com was controlled by the attacker. If one of the forged responses matched the resolver's outstanding query before the legitimate response arrived, the resolver could cache the malicious delegation and associated address information.

Once that information was cached, subsequent queries for names under target.com could be directed to the attacker's nameserver. This significantly increased the potential impact of a successful poisoning attack: instead of corrupting a single DNS record, an attacker could potentially influence resolution for an entire domain.

The Kaminsky disclosure triggered an emergency patch cycle across DNS software vendors. A key short-term mitigation was source port randomization. Randomizing the source port alongside the transaction ID substantially increases the number of values an attacker must guess, making response-racing attacks much more difficult.

The longer-term protocol-level protection is DNSSEC, which adds cryptographic authentication and integrity protection to DNS data. With DNSSEC validation enabled, a resolver can detect forged DNS records that do not have valid cryptographic signatures, rather than relying solely on transaction matching and response-racing defenses.

## DNS hijacking

DNS hijacking occurs when an attacker or intermediary gains control over DNS configuration or infrastructure and uses that control to redirect DNS resolution. Unlike cache poisoning, which attempts to make a resolver accept a forged response, hijacking typically involves changing the DNS settings or authoritative information that determines where queries are resolved.

Different hijacking vectors target different parts of the DNS infrastructure, so each requires different defenses.

### Router hijacking

Router hijacking occurs when malware, compromised credentials, or exploitation of a router vulnerability changes the DNS server settings on a network router. Devices that receive their DNS configuration from the compromised router or its DHCP service are then directed to a malicious or attacker-controlled resolver.

The devices may continue to function normally, while the attacker-controlled resolver selectively redirects queries to phishing sites, malware distribution servers, or other malicious infrastructure. Because the DNS configuration has been changed at the network level, multiple devices can be affected simultaneously.

### Registrar-level hijacking

Registrar-level hijacking targets the account or systems used to manage a domain's registration. An attacker who gains control of a domain owner's registrar account through credential theft, phishing, or social engineering can change the domain's nameserver (NS) records to point to attacker-controlled nameservers.

Because the change occurs in the authoritative DNS delegation, it can affect users globally once the new delegation is observed by recursive resolvers. Existing cached delegation and DNS records can continue to be served until their TTLs expire, so the effect is not necessarily instantaneous.

The 2019 Sea Turtle campaign demonstrated the potential impact of this type of attack. Attackers targeted organizations involved in government, telecommunications, and other sectors and used compromised DNS infrastructure and registrar accounts to redirect traffic.

### Resolver compromise

An attacker who gains administrative access to a recursive resolver can modify its configuration or software behavior directly. Depending on the attacker's privileges, this could allow them to redirect or block queries, return manipulated responses, or monitor DNS requests.

This makes access control a critical DNS security measure. Administrative interfaces should be protected with strong authentication, least-privilege access, network restrictions, and auditing.

### ISP level DNS interception

Some internet service providers have historically intercepted DNS queries sent over traditional DNS on port 53 and modified responses. For example, redirecting NXDOMAIN responses to search or advertising pages. This is different from a domain or resolver being hijacked, but it demonstrates how unencrypted DNS traffic can be altered by an intermediary.

Encrypted DNS protocols such as DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS traffic between the client and its chosen resolver, preventing an intermediary from transparently reading or modifying those queries in transit. However, encrypted DNS does not make the selected resolver inherently trustworthy; users and administrators still need to choose and secure appropriate DNS resolvers.

## DNS amplification attacks

DNS amplification is a distributed denial-of-service (DDoS) technique that abuses the difference between the size of a DNS query and the size of its response. A relatively small DNS query can trigger a substantially larger response, particularly when the response contains DNSSEC records or other large record sets. The ratio between the response and request sizes is known as the amplification factor and can vary significantly depending on the query and the DNS server's response.

### How amplification attacks work

The attacker sends DNS queries to publicly accessible recursive resolvers while spoofing the source IP address to make the queries appear to come from the victim. The resolver processes the query and sends its response to the spoofed source address, causing the victim to receive traffic it did not request.

By sending queries to many resolvers simultaneously, an attacker can use those resolvers as reflection points, turning relatively small volumes of attack traffic into a much larger volume directed at the victim.

Attackers have historically used queries that produce large responses, including ANY queries and requests for DNSSEC-related records such as DNSKEY. Large TXT records can also produce substantial responses. The actual amplification factor varies by query, DNS configuration, response size, and whether the response is transmitted over UDP or requires additional handling because of its size.

### Why open resolvers are a problem

An open recursive resolver accepts recursive queries from arbitrary internet clients rather than restricting recursion to trusted networks or clients. Publicly accessible open resolvers can be abused as reflection points in DNS amplification attacks.

DNS administrators should configure recursive resolvers to accept queries only from authorized clients and networks. Network operators should also implement source-address validation measures such as BCP 38 ingress filtering to prevent attackers from sending packets with spoofed source addresses.

Together, restricting recursive access and preventing source-address spoofing significantly reduces the infrastructure available for DNS reflection and amplification attacks.

## DNS tunneling

DNS tunneling abuses DNS as a covert communication channel. Because DNS is a necessary network service and is commonly permitted through enterprise security controls, attackers can use DNS queries and responses to move data between an infected host and attacker-controlled infrastructure. DNS tunneling can support data exfiltration as well as command-and-control (C2) communication.

### How DNS tunneling works

An attacker encodes data within DNS queries or responses. For example, data from an infected host can be encoded and split into chunks, with each chunk embedded in a subdomain label:

```text
JBSWY3DPEBLW64TMMQ.exfil.attacker-controlled.com
```

The query is sent to a DNS resolver and eventually reaches the authoritative nameserver for the attacker-controlled domain. The attacker can extract the encoded data from the subdomain label. Responses from the attacker's nameserver can similarly carry encoded information back to the infected host.

Attackers can use encodings such as Base32 or hexadecimal, as well as compressed or encrypted data, depending on the tunneling tool and DNS constraints. Because the resulting traffic consists of apparently valid DNS queries and responses, basic network controls that permit DNS may not distinguish the tunnel from legitimate DNS traffic.

### Detection signals for DNS tunneling

DNS tunneling can be difficult to identify from individual queries alone, but analyzing DNS traffic patterns can reveal several indicators:

- **Unusually long or frequently changing query names:** Tunneled data is often split across many subdomain labels, producing query names that are longer or more variable than typical internal DNS traffic.
- **High query volume to an uncommon domain:** An infected host may generate a many queries to the same external domain in a short period.
- **High-entropy subdomain labels:** Encoded, compressed, or encrypted data often produces labels that appear random and contain few recognizable words or patterns.
- **Rare or newly observed domains:** Attacker-controlled infrastructure may use domains that are uncommon or newly observed in the organization's DNS traffic.
- **Unusual record types or response patterns:** TXT and other records can be abused to carry data, while repeated, structured query-response patterns can indicate a command-and-control channel.
- **Consistent query patterns from a single host:** Periodic DNS requests with similar lengths, intervals, and destination domains can indicate automated C2 communication.

DNS monitoring can help identify these behavioral patterns by tracking query volume, domains, record types, response codes, query lengths, and other DNS activity over time.

## DNSSEC: Cryptographic authentication for DNS

DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS data, allowing validating resolvers to verify that DNS responses contain authentic data and have not been modified. It addresses a fundamental weakness of traditional DNS: DNS responses do not inherently provide cryptographic proof of the data's origin or integrity.

### How DNSSEC signing works

DNSSEC uses public-key cryptography to sign DNS resource record sets. A traditional DNSSEC deployment commonly uses two types of keys:

- **Zone Signing Key (ZSK):** Signs the DNS resource record sets in the zone, such as A, MX, and CNAME records. The corresponding signatures are published as RRSIG records.
- **Key Signing Key (KSK):** Used to sign the zone's DNSKEY records. The KSK typically has a longer operational lifecycle than the ZSK, although modern DNSSEC deployments do not require a separate KSK and ZSK.

A Delegation Signer (DS) record in the parent zone contains a cryptographic digest of a DNSKEY record from the child zone. The DS record links the parent and child zones and allows a validating resolver to establish a chain of trust from the DNS root to the requested domain.

The DNS root is DNSSEC-signed and serves as the trust anchor from which validating resolvers can build this chain.

### How DNSSEC validation works

When a DNSSEC-validating recursive resolver receives signed DNS data, it uses the published RRSIG signatures and DNSKEY records to verify the data. It then validates the chain of trust through the relevant DS records in the parent zone, ultimately connecting the domain to a trusted DNSSEC trust anchor.

If the signatures or chain of trust do not validate, the resolver treats the response as bogus and does not return the forged data to the client. Depending on the validation failure, the resolver typically returns SERVFAIL.

This prevents an attacker from successfully poisoning a DNS cache with forged data simply by guessing the transaction ID or source port. Even if an attacker wins the DNS response race, they still cannot generate a valid DNSSEC signature for a zone they do not control.

### What DNSSEC protects and what it does not

| DNSSEC protects against | DNSSEC does not protect against |
|---|---|
| DNS cache poisoning | DNS query privacy |
| Forged DNS responses | DDoS attacks against DNS infrastructure |
| Unauthorized modification of signed DNS data | DNS tunneling |
| DNS data integrity during resolution | Compromise of the authoritative zone or its signing keys |
| Certain forms of DNS hijacking that attempt to redirect a DNSSEC-protected delegation without valid signatures | Compromise of the registrar account or DNS management infrastructure itself |

DNSSEC and [DNS over HTTPS (DoH)](https://www.manageengine.com/products/oputils/tech-topics/dns-over-https.html) are complementary, not alternatives.

DNSSEC authenticates the DNS data itself. It allows a validating resolver to determine whether DNS data is authentic and has not been modified.

DoH encrypts DNS traffic between the client and its resolver. It protects the query and response from being read or modified by intermediaries on that network path.

DNSSEC therefore provides data authenticity and integrity, while DoH provides transport privacy and protection against in-path observation or modification. Using one does not eliminate the security need for the other.

## Response Policy Zones (RPZ): The DNS firewall

Response Policy Zones (RPZ) are a policy mechanism implemented by recursive DNS resolvers that allows administrators to modify DNS responses according to security or organizational policies. Instead of always returning the answer received through normal DNS resolution, an RPZ-enabled resolver evaluates configured policy rules and can block, redirect, or rewrite the response for matching queries.

This effectively creates a DNS firewall that prevents users and devices from resolving known malicious or unauthorized domains before a connection is established. RPZ is commonly used to reduce exposure to phishing websites, malware distribution infrastructure, ransomware command-and-control domains, and other domain-based threats.

### How RPZ works

An RPZ-enabled recursive resolver loads one or more policy zones containing rules for domains or other DNS indicators that should trigger a policy action. When a client requests a matching domain, the resolver applies the configured action instead of returning the normal DNS response.

Depending on the resolver and policy configuration, the action may include:

- Returning NXDOMAIN to indicate that the domain does not exist
- Returning NODATA with no usable record for the requested type
- Redirecting the client to a sinkhole or security information server using a CNAME or replacement address
- Allowing the query to pass through unchanged when an exception applies

These policies are enforced centrally at the recursive resolver, allowing administrators to protect every client that uses that resolver without requiring changes on individual endpoints.

### Using threat intelligence with RPZ

RPZ policies can be created internally by administrators or populated from external threat intelligence feeds that identify malicious domains, phishing infrastructure, botnet command-and-control servers, and other known threats. These feeds are regularly updated so the resolver can apply current blocking policies as malicious infrastructure changes.

For example, if a compromised device attempts to resolve a domain associated with known malware infrastructure, the RPZ-enabled resolver can block or redirect that lookup according to policy. The resulting DNS event can also be logged, giving security teams valuable visibility into devices attempting to contact suspicious domains.

### What RPZ can and cannot protect against

RPZ is effective when a threat depends on DNS resolution through the organization's recursive resolver. It can prevent access to known malicious domains and provide centralized DNS-based policy enforcement across the network.

However, RPZ is not a replacement for DNSSEC or endpoint security. DNSSEC verifies the authenticity and integrity of DNS data, while RPZ intentionally modifies DNS responses based on local policy. RPZ also cannot block threats that bypass DNS entirely by connecting directly to IP addresses or that use domains not yet identified in the configured policy feeds.

## Response Rate Limiting (RRL)

Response Rate Limiting (RRL) limits the rate at which a DNS server sends repeated or similar responses, helping reduce its use in DNS reflection and amplification attacks.

When attackers send spoofed DNS queries that cause large responses to be sent to a victim, RRL detects excessive response patterns and limits the responses, reducing the volume of traffic the DNS server can contribute to the attack.

RRL does not replace other protections. Restricting recursive queries to authorized clients and implementing source-address validation such as BCP 38 are also important for preventing DNS infrastructure from being abused for amplification.

## DNS security visibility with ManageEngine OpUtils

DNS security requires continuous visibility into the DNS infrastructure, records, and changes that can affect network availability and security. [ManageEngine OpUtils](https://www.manageengine.com/products/oputils/) helps enterprise teams monitor and manage DNS environments from a centralized console, with support for [Microsoft DNS](https://www.manageengine.com/products/oputils/microsoft-dns-management.html) and [AWS Route 53](https://www.manageengine.com/products/oputils/aws-route53-dns-management.html).

OpUtils provides visibility into DNS servers and hosted zones, monitors forward and reverse [DNS resolution](https://www.manageengine.com/products/oputils/dns-resolver.html?), and helps validate IP-to-hostname consistency by correlating DNS data with IP address and DHCP information.

By bringing [DNS, DHCP, and IP address](https://www.manageengine.com/products/oputils/ddi.html) data together, OpUtils helps administrators identify resolution failures, inconsistent records, unauthorized changes, and other DNS issues before they affect users and applications.

## FAQs on DNS security

### What is DNS cache poisoning?

DNS cache poisoning is an attack that causes a recursive resolver to cache forged DNS data. An attacker attempts to make the resolver accept a malicious response as the answer to an outstanding query. If successful, the resolver can serve the forged data to clients until the cached record expires or is replaced. DNSSEC helps prevent cache poisoning by allowing validating resolvers to verify the authenticity and integrity of DNS data.