Imagine that an organisation has secured its website properly. The application is patched, access requires multifactor authentication and traffic is encrypted with HTTPS.
An attacker compromises the account used to manage the organisation’s domain and changes a DNS record. Users who enter the correct website address are now sent to infrastructure controlled by the attacker.
The application was not breached. The route leading users to it was changed.
This is why DNS remains valuable to attackers. It operates early in most network connections and is trusted by systems that depend on it. A successful attack can redirect traffic, interrupt services, support credential theft or hide communication with malware.
DNS security is not one server-hardening problem. Different parts of the DNS system perform different jobs, and each creates a different attack surface.
Three DNS roles that should not be confused
| DNS role | What it does | What an attacker gains |
|---|---|---|
| Authoritative DNS | Publishes the official records for a domain | Ability to redirect or disrupt services using that domain |
| Recursive resolver | Finds DNS answers for users and caches them | Ability to influence or observe where many clients connect |
| DNS administration | Controls domains, name servers, records and signing keys | Control over the DNS configuration itself |
An organisation may run some of these functions internally and obtain others from registrars, cloud providers or managed DNS services. Knowing who operates each role is the beginning of securing it.
Why DNS provides so much leverage
It is part of almost every connection
Users work with names such as portal.example.com. Applications ultimately need network addresses and other service information. DNS provides that mapping.
If DNS is unavailable, many applications appear unavailable even when their servers are healthy. If DNS returns a false answer, the client may connect to the wrong destination. This makes DNS both a dependency and a control point.
It serves more than websites
DNS records help locate email systems, identity services, application endpoints and other infrastructure. Technologies such as SPF, DKIM and DMARC also use DNS records as part of email authentication.
Inside Windows environments, DNS is closely connected to Active Directory service discovery. Damage to internal DNS can therefore interfere with authentication, policy application and access to organisational resources.
It was designed for an earlier trust model
Traditional DNS prioritised distributed name resolution and availability. Basic DNS responses were not designed to prove cryptographically that the answer came from the legitimate owner or remained unchanged.
Security extensions and encrypted transports address parts of this weakness, but deployment is not automatic and each control solves a different problem.
The attacks are not all the same
Domain and record hijacking
If an attacker compromises a registrar, DNS-hosting or administrative account, they may change name-server delegation or individual records. This is a control-plane attack: the attacker is using legitimate management functions without legitimate authority.
The consequences can extend beyond website redirection. DNS changes can redirect email, interfere with domain-validation processes or help an attacker obtain trusted certificates in some circumstances.
Strong authentication, restricted administrative roles, registry locks where available, change alerts and an independently stored recovery procedure matter more here than hardening the DNS server software.
Denial of service
Attackers may flood authoritative servers or resolvers until legitimate requests cannot be answered. Because so many applications depend on DNS, one attack can make several services appear offline at once.
Redundant servers in the same building or network do not provide enough resilience. Organisations need provider, network and geographic diversity appropriate to their risk. Managed authoritative platforms often use anycast, which distributes service across many locations, but customers must still protect the accounts and configurations controlling that service.
Cache poisoning
Recursive resolvers cache answers to improve performance. If an attacker causes a resolver to store a forged answer, clients relying on that cache may be sent to an attacker-selected destination.
Modern resolvers include protections, and DNSSEC can allow validation of signed DNS data. Cache poisoning has not disappeared, however. Protocol and implementation work continues because parsing, caching and validation behaviour remain complex.
Reflection and amplification
DNS commonly uses UDP, which does not establish a connection before sending a response. An attacker may forge the victim’s source address and send queries to exposed DNS servers. Those servers then send responses to the victim.
When a small query produces a larger response, the attack gains amplification. Restricting recursive service to approved clients, avoiding open resolvers and applying source-address validation help reduce this misuse.
DNS as a malware channel
Malware must often locate command infrastructure or send information outside the network. Attackers can use rapidly changing domains, generated domain names, fast-flux infrastructure or DNS tunnelling to make that communication harder to block.
DNS is therefore not only something to protect. It is also valuable security telemetry. Unusual query volumes, long encoded-looking names, newly registered domains and repeated failures may reveal compromised devices.
What DNSSEC and encrypted DNS actually solve
DNS security discussions often treat DNSSEC, DNS over HTTPS and DNS over TLS as interchangeable improvements. They protect different properties.
DNSSEC allows a validating resolver to verify the origin and integrity of signed DNS data. It helps defend against forged responses and cache poisoning. It does not encrypt the query, hide which domain was requested or keep a DNS service available during an attack.
DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS traffic between a client and resolver. This protects the query from simple observation or alteration on that path. It does not prove that the domain owner published the correct record, and it does not make the selected resolver trustworthy.
Encrypted DNS also creates an operational trade-off. If devices silently use external resolvers, an organisation may lose policy enforcement and monitoring at its approved DNS service. Secure deployment therefore requires more than enabling encryption; it requires deciding which resolvers are authorised and how DNS activity will remain observable.
A practical defensive model
Protect the authority
- Use phishing-resistant multifactor authentication for registrar and DNS-hosting accounts where supported.
- Separate daily user accounts from DNS administration.
- Restrict who can alter delegation, records and DNSSEC keys.
- Alert on name-server, zone, record and account changes.
- Keep recovery contacts and proof of domain ownership outside the affected DNS platform.
Separate the roles
Authoritative servers should publish zones. Recursive resolvers should answer clients. Combining public authoritative service with unrestricted recursion increases exposure and makes policy harder to reason about.
Limit recursion to approved networks or identities. Permit zone transfers only to authorised secondary servers. Keep management interfaces off the public internet wherever practical.
Design for failure
Use independent authoritative servers and remove single-provider or single-network dependencies when the business impact justifies it. Monitor DNS from outside the organisation so failures can be detected even when internal monitoring depends on the same DNS service.
Back up zone data and configuration, but also test restoration. A backup does not solve registrar compromise or malicious delegation changes unless the recovery process covers those layers.
Use DNS as a security control
Protective DNS services block resolution of known malicious domains before a connection is made. CISA and the UK National Cyber Security Centre describe protective DNS as a way to reduce the effectiveness of phishing, malware, botnet and ransomware activity.
Collect resolver logs with appropriate privacy and retention controls. Connect DNS events with endpoint, identity and network evidence. A suspicious query becomes more useful when analysts can identify the requesting device, user and subsequent connection.
Patch the entire path
DNS security depends on more than dedicated DNS software. Operating systems, routers, firewalls, registrars, management portals and automation credentials may all influence DNS behaviour.
In 2026, the UK National Cyber Security Centre reported that APT28 exploited vulnerable routers to enable DNS hijacking and adversary-in-the-middle activity. The lesson is broader than that campaign: an attacker may manipulate DNS through surrounding infrastructure rather than compromise the authoritative server directly.
What technology professionals need to know
Most developers do not need to operate DNS servers, but they should understand that an application’s availability and identity begin before the request reaches their code.
Cloud and platform engineers should know which service is authoritative, which resolvers workloads use, how private and public zones interact, and how DNS fails across regions. Security teams should treat domain administration as privileged infrastructure and use DNS logs as part of detection. Leaders should know who can recover the domain if the normal administrative account is unavailable or compromised.
The most useful first question is simple:
If our DNS answers became unavailable or untrustworthy today, which services would fail—and who could restore authority?
If nobody can answer confidently, the organisation has found a security and resilience gap worth fixing.
Go deeper
- NIST SP 800-81 Revision 3: Secure Domain Name System Deployment Guide — current guidance for authoritative DNS, recursive resolvers, DNSSEC, encrypted DNS, protective DNS and deployment security. Published March 2026.
- CISA and NSA guidance on Protective DNS — explains how DNS filtering can reduce exposure to malicious domains.
- RFC 7873: Domain Name System Cookies — describes limited protection against denial-of-service, amplification, forgery and cache-poisoning attacks.
- Microsoft guidance for securing DNS zone transfers — practical guidance for restricting Windows DNS zone transfers.
- NCSC advisory on APT28 DNS hijacking — a 2026 example of DNS manipulation through compromised surrounding infrastructure.