DNS Security: Protecting the First Connection
DNS is one of the foundational services behind almost every digital application. Before a browser connects to a website, a device reaches a cloud service, or an application establishes a session, DNS is often involved in identifying the destination. That makes DNS more than a directory of names and IP addresses — it is an important security and visibility control point.
A modern DNS security architecture therefore needs to address several different problems at the same time: where DNS traffic is allowed to go, whether DNS data can be trusted, whether destinations are considered safe, and whether unusual DNS behaviour can be detected.
How can an organisation use DNS to protect the earliest stage of a connection without confusing DNS encryption, DNS filtering and DNSSEC as if they solved the same security problem?
01 · The Security Context DNS Is More Than Name Resolution
Traditional DNS provides a distributed mechanism for translating human-readable hostnames into addresses. Its hierarchical design, delegation model and caching make Internet-scale name resolution practical. But the original protocol was not designed around the security expectations of today's Internet.
Modern environments contain unknown Internet participants, cloud applications, remote users, unmanaged devices and constantly changing infrastructure. As a result, DNS has become both a critical dependency and an attractive attack surface.
Find the Destination
Recursive resolution, caching and delegation allow clients to discover the DNS information required to reach an application or service.
Evaluate the Destination
Filtering and threat intelligence can determine whether a requested domain should be allowed, blocked or redirected for further inspection.
Understand the Behaviour
DNS telemetry provides evidence about which domains devices are requesting, how frequently they are queried and whether unusual patterns are emerging.
02 · Three Different Problems Privacy, Integrity and Trust
One of the most important engineering distinctions in DNS security is that different technologies protect different properties. Encrypting a DNS query does not prove that the destination is safe. Filtering a domain does not authenticate the DNS response. DNSSEC validation does not provide complete visibility into endpoint behaviour.
DoH and DoT can protect DNS traffic between a client and its selected resolver from passive observation on the transport path.
DNSSEC provides cryptographic validation of signed DNS data and helps detect manipulation of responses when the relevant chain of trust is available.
DNS filtering evaluates requested destinations against security policy, reputation and threat intelligence to determine whether resolution should proceed.
DNS Filtering
Filtering can block known malicious, phishing, command-and-control or otherwise prohibited domains before a connection is established. It is a policy decision, not a cryptographic proof of authenticity.
DNSSEC
DNSSEC uses digitally signed DNS data and a hierarchical chain of trust to validate responses. It addresses authenticity and integrity rather than domain reputation.
DoH / DoT
DNS over HTTPS and DNS over TLS encrypt the client-to-resolver connection. Encryption protects the channel but does not determine whether the requested domain is malicious.
DNS Telemetry
Resolver and security logs expose DNS behaviour that can be correlated with endpoint, identity, network and application evidence during investigation.
Where DNS Security Controls Operate
03 · Why DNS Becomes an Attack Surface Security Starts Before the Application Session
Because DNS commonly occurs before an application connection is established, attackers can abuse the protocol at an early stage of the attack chain. DNS can be manipulated to redirect users, used to communicate with command-and-control infrastructure, abused for data exfiltration, or overwhelmed to disrupt service availability.
Examples include cache poisoning, DNS spoofing or hijacking, DNS tunnelling, amplification attacks, DNS floods and random-subdomain or NXDOMAIN attacks. Each produces different evidence and requires a different combination of controls.
Poisoning & Spoofing
Incorrect DNS information can redirect clients towards unintended destinations or cause a resolver to return manipulated data.
DNS Tunnelling
Encoded information can be carried inside DNS queries and responses, creating a potential channel for command-and-control or data exfiltration.
Flood & Amplification
DNS infrastructure can be targeted directly or abused as part of reflected and amplified denial-of-service activity.
04 · Architectural Response Build DNS Security as a Control Stack
A resilient DNS security design should therefore avoid treating any individual feature as the complete solution. Filtering, DNSSEC, encrypted DNS transport, resilient resolver infrastructure, logging and threat intelligence address different parts of the problem.
The result is a layered security model in which DNS provides both an enforcement point and an early source of security telemetry. Suspicious DNS behaviour can be blocked, investigated or correlated with other evidence before the associated application session becomes the primary security signal.
DNS should be treated as part of the security architecture rather than as a background network service. The strongest design combines secure transport, DNS filtering, DNSSEC validation, resilient infrastructure and continuous telemetry. The key engineering principle is simple: each control solves a different problem, and effective DNS security comes from combining those controls with broader endpoint, identity, network and application evidence.
DNS Security — Engineering Guide
DNS as a Security Control Plane: Architecture, Telemetry and Investigation
Follow a DNS request before looking at the security problem
DNS security makes more sense when the normal resolution process is understood first. Select a stage below to see what happens at that point in the request path.
Client
A user, device or workload requests a name.
Resolver
The recursive resolver processes the query.
Security Policy
Filtering and intelligence can inspect the request.
Authoritative DNS
Authoritative infrastructure supplies DNS data.
DNS as a Security Control Plane
DNS is traditionally viewed as a resolution service: a client asks for a hostname and a resolver returns the information required to reach the destination. In a modern security architecture, however, the resolver can become much more than a lookup mechanism.
Because DNS activity normally occurs before an application connection is established, it provides an early opportunity to apply policy, evaluate destination risk and collect security telemetry.
01 · The Architectural Shift From Resolver to Security Control Point
A traditional DNS deployment focuses primarily on availability and resolution. The resolver answers queries, follows delegation, caches records and returns the information requested by clients.
A security-aware resolver adds another layer of responsibility. It can become the point where DNS requests are evaluated against threat intelligence, reputation data, organisational policy and identity context before the connection continues.
DNS does not need to replace the firewall, endpoint security or application security. Its value comes from providing an early control point that can make a security decision before the requested application session begins.
02 · DNS Architecture Three Operational Planes
It is useful to think about modern DNS security in terms of three operational planes. The terminology differs between products and architectures, but the engineering responsibilities remain broadly similar.
Recursive Resolution
The resolver performs recursive lookups, follows DNS delegation, caches responses according to TTL values and returns DNS information to the requesting client.
Policy & Enforcement
DNS requests can be evaluated against domain reputation, threat intelligence, filtering rules, identity context and organisational policy. A request may be allowed, blocked or redirected for additional inspection.
Telemetry & Detection
DNS queries, responses, policy decisions and anomalies can become security telemetry. This information can then be correlated with endpoint, identity, network and application evidence.
03 · Resolution Path Where Security Decisions Can Be Applied
The DNS resolution path provides several opportunities for inspection. The precise architecture varies between enterprise, cloud and managed DNS environments, but the basic security model can be represented as a sequence of resolution, evaluation, validation and observation.
04 · Security Stack Different Controls Solve Different Problems
A common architectural mistake is to treat DNS encryption, DNS filtering and DNSSEC as interchangeable security controls. They are not. Each protects a different property of the DNS process.
DoH / DoT
Encrypts the DNS connection between a client and its selected resolver. This helps protect the query from passive observation on the transport path, but does not establish that the destination is safe.
DNS Filtering
Uses policy, reputation and threat intelligence to determine whether a requested domain should be resolved. Filtering is primarily an access-control and threat-prevention mechanism.
DNSSEC
Uses cryptographic signatures and a chain of trust to validate DNS data. It addresses integrity and authenticity rather than domain reputation.
DNS Telemetry
Captures query behaviour, responses, policy decisions and anomalies. Telemetry provides the evidence needed for detection, investigation and threat hunting.
05 · Operational Security DNS Becomes a Security Sensor
The value of DNS telemetry comes from the patterns that appear across many requests rather than from a single DNS event. A single unusual domain does not necessarily indicate compromise. A sequence of rare domains, unusual query lengths, abnormal NXDOMAIN activity or repeated connections to suspicious infrastructure can provide a much stronger signal.
Turn DNS Activity into Evidence
06 · Engineering Checklist Designing DNS as a Security Control Plane
DNS becomes significantly more valuable when it is treated as a security control plane and telemetry source rather than simply a resolution service. The resolver can provide the point where requests are evaluated, DNSSEC can validate signed data, encrypted DNS can protect the transport and telemetry can expose suspicious behaviour. The important engineering principle is that these controls are complementary — no single DNS technology solves the entire security problem.
Follow One DNS Query Through the Network.
Application
RESOLVER
Resolver
POLICY
Filtering
DNS Threats: Where Resolution Becomes an Attack Surface
Where can the DNS process be attacked?
DNS attacks do not all target the same property. Select an attack class to see the primary security concern behind it.
The security objective is to ensure that clients receive the correct DNS information rather than an attacker-controlled destination.
DNS Threats: Where the Resolution Process Becomes an Attack Surface
DNS was designed to provide scalable name resolution rather than to act as a security system. That distinction matters. The same distributed architecture that makes DNS efficient and resilient can also provide attackers with opportunities to manipulate responses, hide activity, exhaust resources or use DNS as a communications channel.
Modern DNS security therefore begins with understanding how the attack changes the normal resolution process. Some attacks target the integrity of DNS data. Others target availability. Others abuse DNS itself as a transport mechanism for command-and-control or data exfiltration.
The Major DNS Attack Classes
The most useful way to understand DNS threats is to separate them by the security property they attempt to undermine. This makes it easier to select an appropriate control rather than treating every DNS security problem as a generic filtering problem.
DNS Cache Poisoning
An attacker attempts to introduce incorrect DNS information into a resolver's cache so that subsequent clients receive an unintended destination address.
DNS Spoofing & Hijacking
DNS responses or resolution behaviour are manipulated so that users are directed somewhere other than the intended destination. The attack can occur at different points in the resolution path.
DNS Amplification
Attackers abuse exposed or poorly configured DNS infrastructure to generate responses toward a victim, using asymmetric request and response sizes to amplify traffic.
DNS Flooding
DNS servers or their supporting network infrastructure are overwhelmed with large volumes of requests, reducing the ability of legitimate clients to obtain resolution.
Random Subdomain / NXDOMAIN Attacks
Large numbers of unique, nonexistent names can generate repeated NXDOMAIN processing and reduce resolver or authoritative-server efficiency.
DNS Tunnelling
DNS queries and responses can be abused to carry encoded information, enabling covert command-and-control or data-exfiltration channels that may blend into normal DNS traffic.
Attack Path: From DNS Request to Security Impact
A DNS attack does not necessarily begin with a malicious-looking packet. In many cases the initial request can appear syntactically normal. The security problem emerges from the destination, frequency, response behaviour, context or relationship between multiple DNS events.
DNS Cache Poisoning
DNS cache poisoning attempts to place false information into a recursive resolver's cache. Once the incorrect record is cached, clients using that resolver may receive the malicious destination until the cached information expires or is replaced.
The fundamental security problem is therefore data integrity. A resolver may successfully complete the DNS transaction from a protocol perspective while still returning an incorrect answer. This is why DNSSEC provides a fundamentally different security function from DNS filtering.
DNS Spoofing and Hijacking
DNS spoofing describes situations where false DNS information is presented to a client or resolver. DNS hijacking can occur when an attacker or intermediary gains the ability to alter DNS settings, responses or resolution behaviour.
The important engineering distinction is that the user may still perform a perfectly normal DNS lookup from the endpoint's perspective. The problem is that the lookup has been influenced by another party. This can redirect users toward phishing infrastructure, malicious services or unwanted destinations.
DNS Amplification and Flood Attacks
Availability attacks target a different property. Rather than attempting to make DNS return the wrong answer, the attacker attempts to prevent legitimate users from obtaining answers at all.
DNS Amplification
- Uses DNS infrastructure as a traffic reflector.
- Often relies on spoofed source addresses.
- Attempts to generate a larger response toward the victim.
- Can contribute to large distributed denial-of-service attacks.
DNS Flooding
- Directly overwhelms DNS infrastructure with requests.
- Consumes processing, bandwidth or connection capacity.
- Can affect legitimate DNS resolution.
- Requires resilience, capacity and traffic protection.
Random Subdomain and NXDOMAIN Attacks
A random-subdomain attack generates large numbers of queries for names that do not exist. The resulting NXDOMAIN responses create additional processing requirements for recursive and authoritative infrastructure.
This demonstrates why DNS security cannot focus exclusively on malicious domains. A domain can be legitimate while the behaviour associated with the query is abnormal. Query volume, uniqueness, timing, source identity and response patterns can therefore become important detection signals.
DNS Tunnelling
DNS tunnelling represents a different type of abuse. Instead of attacking DNS resolution directly, the attacker uses DNS as a communication mechanism. Data can be encoded into DNS queries and responses, allowing information to move through infrastructure that permits DNS traffic.
This can support command-and-control communication or data exfiltration. Because DNS is ubiquitous and required by many environments, simply allowing DNS traffic does not mean that all DNS activity should be considered trusted.
Why DNS Creates a Security Blind Spot
DNS is frequently treated as background infrastructure. Applications depend on it, firewalls allow it, and users rarely interact with it directly. This can make DNS activity difficult to notice until something goes wrong.
The security challenge is therefore not simply that DNS has vulnerabilities. It is that DNS activity can provide attackers with a highly available channel that may not receive the same depth of inspection as web, application or endpoint traffic.
This is particularly important for DNS tunnelling and command-and-control activity. A security architecture that only evaluates the final application connection may miss useful evidence contained in the DNS activity that occurred before that connection was established.
DNS attacks fall into several distinct classes: integrity attacks can manipulate resolution data, availability attacks can disrupt resolution, and protocol abuse can turn DNS into a covert communications channel. Effective DNS security therefore requires more than domain blocking. It combines validation, filtering, resilience and behavioural visibility so that the security team can understand both what DNS returned and how DNS was being used.
Inject a DNS Attack. Follow the Evidence.
Workstation
RESOLVER
DNS Service
DNS
Zone Data
DNS Security Controls: Filtering, Validation, Encryption and Visibility
Four controls — four different security problems
DNS filtering, DNSSEC, encrypted DNS and telemetry are often discussed together. Select each control to see the specific security property it addresses.
DNS Filtering
Evaluates requested domains against policy and threat intelligence so known malicious or prohibited destinations can be blocked before the connection proceeds.
Protects the security decisionDNS Security Controls: Filtering, Validation, Encryption and Visibility
DNS security is not a single feature that can simply be switched on. Effective protection comes from combining controls that address different properties of the DNS transaction: what is being requested, who is requesting it, whether the response is authentic, how the query is transported, and what the activity reveals about the wider attack.
If DNS filtering blocks a malicious domain, DNSSEC validates the response, and DoH encrypts the query path, are those controls solving the same problem? No. Each protects a different part of the DNS security model.
Protect the decision
DNS filtering and threat intelligence determine whether a requested domain should be allowed, blocked, redirected or investigated.
Protect the channel
DNS over TLS and DNS over HTTPS encrypt DNS communication between a client and its resolver, reducing exposure to interception and manipulation in transit.
Protect integrity
DNSSEC provides cryptographic validation so a resolver can determine whether signed DNS data is authentic and has not been altered.
Protect visibility
DNS logging, telemetry and behavioural analysis turn resolution activity into security evidence that can be correlated with users, devices and threats.
DNS Filtering & Threat Intelligence
Filtering evaluates the requested domain against security policy, reputation data and threat intelligence. A request associated with malware, phishing, command-and-control infrastructure or another prohibited category can be blocked before the connection proceeds.
DNSSEC Validation
DNSSEC adds cryptographic signatures to DNS data and allows validating resolvers to establish the authenticity and integrity of signed responses. It addresses a fundamentally different problem from domain reputation.
DNS over HTTPS / TLS
DoH and DoT encrypt the communication between the DNS client and resolver. This reduces the ability of intermediate networks to inspect or manipulate DNS requests in clear text.
DNS Logging & Analytics
DNS telemetry provides a security view of the destinations being requested across users, endpoints and workloads. Patterns such as repeated failures, unusual query volumes or suspicious domain relationships can become early indicators of compromise.
DNS policy can become identity-aware
Traditional DNS policy often starts with an IP address or network segment. Modern security architectures can associate DNS activity with the identity and context behind the request. This allows policy to consider the user, device, workload, location or security posture rather than treating every query from a network as equivalent.
DNS becomes particularly useful in Zero Trust and SASE architectures because name-resolution activity occurs before many application connections are established. A DNS security service can therefore provide an early policy and visibility point across users, endpoints, branches and cloud workloads.
Cloud-delivered DNS security
DNS requests are sent to a security service that combines policy enforcement, threat intelligence, filtering and telemetry. This model can provide consistent controls across distributed users and locations.
On-premises DNS security
Resolver infrastructure and security controls remain within the organisation. This can provide direct operational control and integration with existing internal DNS architecture.
Hybrid DNS security
Internal and external resolution paths are combined so that private zones, enterprise policy, cloud workloads and Internet-facing DNS can be protected according to their different requirements.
Architecture-aware controls
Enterprise platforms can combine DNS security with broader secure-access, cloud, identity and monitoring capabilities, making DNS one component of a larger security architecture.
DNS security works best as a layered control system. Filtering decides what should be allowed, threat intelligence supplies context, DNSSEC protects the integrity of signed DNS data, DoH and DoT protect the resolver communication channel, and DNS telemetry provides the visibility required to detect and investigate abnormal behaviour. No single control replaces the others.
One DNS Query. Four Security Controls.
10.10.10.24
Protected channel
Threat intelligence
DNSSEC data
DNS as a Security Control Plane: Architecture, Telemetry and Investigation
Turn a DNS event into an engineering investigation
A suspicious DNS query is a signal, not automatically a verdict. Follow the investigation path and combine DNS evidence with identity, endpoint and network context.
Determine which user, endpoint, server, application or workload generated the DNS request before deciding whether the activity is suspicious.
DNS as a Security Control Plane: Architecture, Telemetry and Investigation
The value of DNS security extends beyond blocking malicious domains. When DNS requests are consistently controlled, logged and analysed, the resolver becomes a strategic observation point across the network. It can connect identity, destination, policy, threat intelligence and behavioural telemetry before an application session is fully established.
Treat DNS as part of the security architecture rather than as an isolated naming service. The objective is not simply to make DNS harder to attack; it is to make DNS useful for prevention, validation, detection and investigation.
Users · Devices · Workloads
DNS requests originate from endpoints, servers, applications, branches and cloud workloads.
Secure DNS Control
Encrypted transport, policy enforcement, threat intelligence, filtering and DNSSEC validation.
Authoritative DNS / Internet
Resolution continues toward authoritative infrastructure and the requested destination.
Observe
Capture DNS requests, responses, identities, destinations, response codes and behavioural patterns.
Decide
Apply security policy and intelligence to determine whether a request should proceed, be blocked or be investigated.
Validate
Validate response integrity where DNSSEC is available and identify inconsistencies or unexpected resolution behaviour.
Investigate
Use DNS telemetry as evidence when searching for malware, tunnelling, command-and-control activity or compromised systems.
Normal resolution behaviour
Potential anomaly signals
From query to security decision
A DNS event should not automatically be treated as an attack. The investigation process should combine DNS evidence with identity, endpoint, application and network context. This avoids turning a single unusual query into a false positive while still allowing patterns to surface early.
A DNS query becomes a security signal
DNS security platforms and custom analytics can evaluate multiple attributes rather than relying on a single rule. This makes it possible to detect behaviour that may not match a known malicious domain.
The strategic value of DNS security is visibility combined with control. A secure DNS architecture can prevent access to known malicious destinations, protect DNS communication, validate signed responses and expose behavioural anomalies. When that telemetry is correlated with identity and endpoint evidence, DNS becomes an early security control plane rather than simply a background network service.