DNS Security & Abuse Introductory 6 min read

Why Attackers Use DNS

An architectural explanation of why DNS is frequently abused, rooted in how the protocol is designed and operated.

Updated January 27, 2026

DNS was not designed with attackers in mind. It was designed to be simple, global, and resilient. Those same properties make it attractive for abuse. Understanding why attackers use DNS requires looking at the protocol’s architecture and operating assumptions, not at specific threat campaigns.

This article explains why DNS is repeatedly reused by attackers, without framing DNS as broken or insecure by default.

Diagram comparing six DNS design properties with how attackers exploit each one — ubiquity ensures DNS is always permitted, distribution limits visibility, delegated trust enables cheap disposable domains, lightweight responses provide high leverage, quiet traffic is hard to spot, and fault tolerance masks anomalies
Figure 1: The same architectural properties that make DNS reliable also make it attractive for abuse.

DNS Is Required for Almost Everything

Most networked applications rely on DNS before they can do anything useful. A browser cannot fetch a web page, a mail server cannot deliver email, and an endpoint cannot reach an update service without first resolving a name.

This makes DNS a dependable starting point. If an attacker controls or influences DNS responses, they can affect many downstream systems without needing to directly compromise those systems.

The importance of DNS also means it is rarely disabled. Networks may restrict ports, protocols, or destinations, but DNS resolution is usually allowed because basic functionality depends on it.

Did you know?
Most malware doesn't need to bring its own DNS logic. It can simply call the [operating system's built-in resolver](/library/stub-resolvers-the-dns-you-actually-use), piggybacking on legitimate infrastructure with no additional code.

DNS Is Distributed and Loosely Coupled

DNS is not a single service or control point. It is a distributed system made up of clients, recursive resolvers, authoritative servers, and caches operated by many independent parties.

This loose coupling is intentional. It improves resilience and scalability. It also means that no single actor has complete visibility or control over how a name is resolved end to end.

Attackers can take advantage of this distribution by placing infrastructure in parts of the system that are hard to observe directly, such as authoritative zones hosted with commodity providers or fast-changing subdomains with short time to live values.

DNS Trust Is Delegated, Not Centralized

DNS works through delegation. Each zone is responsible for its own data, and resolvers generally trust authoritative answers once delegation is established.

There is no global approval process for creating domains or publishing records. As long as delegation is valid and responses are syntactically correct, they are usually accepted.

This makes DNS flexible and scalable. It also means attackers can create and abandon domains cheaply, moving faster than many detection or response processes.

Did you know?
A domain registered for a few dollars can serve as command infrastructure for weeks before it appears on any blocklist. By the time it's flagged, the attacker has moved on.

DNS Responses Are Small but Powerful

A DNS response contains very little data, but that data influences important decisions. An IP address returned in an A or AAAA record determines where traffic is sent. An MX record determines where email is delivered.

Because of this leverage, DNS can be used as a control channel. Changing a record can redirect traffic, activate dormant behavior, or disable communication, often without modifying any client-side configuration.

Short TTLs amplify this effect by allowing changes to propagate quickly while still using standard DNS mechanisms.

RFC reference
DNS delegation and resolution behavior are defined in RFC 1034 and RFC 1035.

DNS Traffic Looks Ordinary

DNS queries are common, frequent, and repetitive. They occur on almost every network, generated by operating systems, applications, and background services.

This normalcy makes DNS traffic difficult to distinguish at a glance. Malicious queries often resemble legitimate ones in structure and timing, especially when they are embedded in expected application behavior.

Encrypted DNS transports such as DNS over HTTPS and DNS over TLS further reduce visibility for intermediaries. This improves user privacy but also limits inspection opportunities.

Diagram showing four applications making DNS queries — a browser, mail client, system updater, and malware — where all four produce identical UDP port 53 A record queries at the network layer, making the malicious query indistinguishable from the legitimate ones
Figure 2: At the network layer, a malicious DNS query is structurally identical to a legitimate one.

DNS Fails Softly

When DNS fails, systems often retry, fall back, or degrade gracefully. Clients may query multiple resolvers, reuse cached data, or attempt alternate names.

This tolerance for partial failure is essential for reliability. It also allows abusive behavior to blend into background noise. Unusual patterns may not immediately break anything, making them harder to notice.

Case example
A client repeatedly queries a non-existent subdomain. Each query fails independently, but the overall application continues running, masking the behavior unless aggregate patterns are analyzed.

DNS Is Not the Vulnerability

DNS is attractive to attackers because it does exactly what it was designed to do. It provides a global, reliable naming system with minimal friction and broad reach.

Abuse arises from how DNS fits into larger systems, not from a single flaw in the protocol. DNS does not authenticate intent (DNSSEC verifies the origin and integrity of responses, but not whether a response is benign), and it was never meant to.

Understanding this distinction matters. It shifts the conversation away from treating DNS as broken and toward understanding how its design choices create both strengths and predictable risks.

Summary

Attackers use DNS because it is ubiquitous, distributed, trusted by design, and operationally quiet. These are architectural properties, not implementation mistakes.

Defensive approaches that respect how DNS actually works, such as DNS filtering applied at the resolver layer, tend to be more effective than those that assume DNS can be tightly controlled without tradeoffs.