DNS (Domain Name System) is the phone book of the internet: it translates human-readable names like decripte.com.br into IP addresses. Designed in the 1980s on the assumption of a trusted network, it was born without native authentication or encryption. Decades later, that legacy has turned DNS into one of the most exploited attack vectors and, at the same time, one of the most valuable sources of telemetry for detection. This article explains why DNS is a target, which threats exploit it and how DNSSEC, DNS over HTTPS/TLS, protective DNS and SOC monitoring make up a layered defense.
Why DNS is a priority target
Almost every communication on the internet begins with a DNS query. Before a browser opens a site, an email is delivered or malware contacts its command-and-control server, there is a name resolution. This ubiquity makes DNS a strategic layer for both the attacker and the defender.
The structural problem is that the classic DNS protocol was conceived as trusted by default. Responses mostly arrive over UDP on port 53, in clear text and without any proof of authenticity. The client has no way to verify whether the response really came from the legitimate authoritative server or was forged by a third party along the path. There is also no confidentiality: any device on the route — a provider, a public Wi-Fi hotspot or an adversary in a man-in-the-middle position — can read and log which domains a user queries.
These two gaps — lack of integrity and lack of confidentiality — are the root of nearly all the threats that follow, and each modern DNS security mechanism specifically attacks one of them.
The main threats to DNS
Cache poisoning and spoofing
In cache poisoning, the attacker injects fake DNS records into a recursive resolver. Because the resolver caches responses to speed up future queries, a single forged record can redirect thousands of users to a malicious server. The classic Kaminsky attack (2008) showed how guessing the transaction identifier and the source port allowed forging responses before the legitimate one arrived, sending users of a bank or webmail to phishing pages without anything looking wrong in the address bar.
DNS hijacking
DNS hijacking occurs when the attacker alters the resolution configuration of a victim or an organization. It can happen on the home router (changing the configured DNS servers), in the domain registrar account (compromising credentials and pointing NS records to hostile servers) or via malware on the endpoint. The campaign known as Sea Turtle, warned about by CISA, compromised registrars and providers to redirect the traffic of entire government agencies.
DNS tunneling: exfiltration and C2
Because DNS traffic is almost always allowed through firewalls — after all, without DNS nothing works — attackers use it as a covert channel. In DNS tunneling, data is encoded in query subdomains (for example ZXhmaWx0cmFkbw.attacker.com) and responses, creating a bidirectional channel to exfiltrate sensitive data or maintain command-and-control (C2) communication. Anomalous volumes of TXT queries, high-entropy domains and excessively long names are classic signs of this abuse.
DDoS via DNS amplification
Open and misconfigured resolvers can be used to amplify denial-of-service attacks. The attacker sends small queries with a spoofed source address (the victim's) and triggers much larger responses, multiplying the traffic aimed at the target. Records such as ANY and responses with DNSSEC, being large, are especially attractive for this reflection and amplification technique.
Domain shadowing and typosquatting
In domain shadowing, the criminal compromises the DNS account of a legitimate domain and creates malicious subdomains under it, inheriting the parent domain's reputation and evading block lists. Typosquatting, on the other hand, registers misspelled variations of well-known brands (for example decrlpte.com.br) to capture inattentive traffic, host phishing or distribute malware. Both techniques exploit the user's visual trust in the domain name.
DNSSEC: ensuring integrity and authenticity
DNSSEC (DNS Security Extensions), standardized in RFC 4033, 4034 and 4035, adds a layer of cryptographic signatures to DNS. Instead of blindly trusting a response, the resolver can now verify that it was signed by the legitimate zone and was not tampered with along the way.
The mechanism relies on a few new records:
- DNSKEY — publishes the zone's public keys, used to verify the signatures.
- RRSIG — contains the digital signature of a set of records (RRset).
- DS (Delegation Signer) — a hash of the DNSKEY published in the parent zone, creating the chain-of-trust link between levels.
- NSEC/NSEC3 — authenticate the non-existence of a name, preventing the forgery of negative responses.
Security stems from a chain of trust that starts at the internet root (the . zone, whose key is managed in public ceremonies) and descends to the domain: the root signs the TLD (.br), which signs decripte.com.br. Each level publishes a DS record that anchors the key of the next level. If any signature does not match, the validating resolver treats the response as invalid (SERVFAIL) and does not deliver it.
It is crucial to understand what DNSSEC protects and what it does NOT protect. It ensures integrity and authenticity — you know the response is authentic and was not tampered with. It does not offer confidentiality: queries and responses still travel in clear text, visible to anyone watching the network. DNSSEC also does not protect against DDoS (in fact, its larger responses can worsen amplification) nor against compromise of the registrar account itself. That is why it solves cache poisoning and spoofing, but needs to be combined with other controls.
DNS over HTTPS (DoH) and DNS over TLS (DoT): confidentiality
If DNSSEC handles integrity, DoT and DoH handle confidentiality, encrypting the transport of queries so that no one along the way can read or alter which domains are being resolved.
DNS over TLS (DoT), defined in RFC 7858, encapsulates DNS traffic inside a TLS connection on a dedicated port (853). By using its own port, it is easily identifiable and manageable by the network team — an advantage for corporate environments that want to control and inspect its use.
DNS over HTTPS (DoH), defined in RFC 8484, sends DNS queries as HTTPS requests on port 443, blending in with ordinary web traffic. This maximizes privacy against observers, but also creates a governance challenge: because DoH is indistinguishable from normal HTTPS traffic, browsers and applications can bypass the corporate resolver and its security policies. For this reason, many organizations disable native browser DoH and channel it to their own managed resolver.
Important: DoT and DoH protect the transport between the client and the recursive resolver, but they do not replace DNSSEC, which protects the authenticity of the data end to end. The technologies are complementary, not competitors.
Protective DNS and DNS filtering as a security control
Beyond protecting the protocol, DNS can be turned into a policy enforcement point. The concept of protective DNS (PDNS), promoted by CISA and the NSA, uses a resolver that consults threat intelligence and blocks or redirects queries to known malicious domains — phishing, malware C2, exfiltration sites — before the connection is established.
DNS filtering applies the same logic for governance and security purposes: entire categories (gambling, newly registered domains, adult content) can be blocked by policy. Because every malicious connection begins with a resolution, stopping it at DNS is cheap, scalable and effective even when the endpoint does not yet have a signature for the malware. It is one of the most cost-effective ways to reduce an organization's attack surface, at any size.
DNS monitoring in the SOC and SIEM
DNS is one of the richest log sources for detection. Centralizing query logs in the SIEM lets the SOC hunt for anomalous behavior that escapes other controls. Patterns of interest include:
- Queries to newly registered or low-reputation domains, often used in new campaigns.
- Long, high-entropy subdomains, a sign of tunneling and exfiltration.
- Spikes in TXT or NULL queries outside the baseline pattern.
- Beaconing — periodic, regular queries to the same domain, typical of C2.
- Domain generation algorithms (DGA), with many sequential NXDOMAIN.
Correlating this telemetry with threat intelligence and with the other logs (proxy, EDR, firewall) elevates DNS from a simple network utility to a front-line detection sensor. The publication NIST SP 800-81 (Secure Domain Name System Deployment Guide) is a reference for architecting this infrastructure with security from the design stage.
Table: threats, mechanisms and mitigations
| Threat | What it exploits | Main mitigation |
|---|---|---|
| Cache poisoning / spoofing | Lack of authenticity of responses | DNSSEC (RRSIG/DNSKEY/DS); port and TXID randomization |
| DNS hijacking | Compromise of config or registrar | MFA and registry lock at the registrar; DNSSEC; NS monitoring |
| DNS tunneling (exfiltration/C2) | Port 53 allowed as a covert channel | Inspection and log analysis in the SIEM; protective DNS; entropy detection |
| DDoS via amplification | Open resolvers and large responses | Close open recursion; rate limiting (RRL); anti-spoofing BCP38 |
| Domain shadowing | Compromised legitimate DNS account | MFA on the DNS account; subdomain monitoring; PDNS |
| Typosquatting | Visual trust in the name | Brand monitoring; blocking newly registered domains; filtering |
| Interception / surveillance | Queries in clear text | DNS over TLS (DoT) and DNS over HTTPS (DoH) |
| Access to malicious domains | Resolution without policy | Protective DNS / DNS filtering with threat intel |
A layered defense
No single mechanism solves DNS security. DNSSEC ensures you receive the right response; DoT/DoH ensure no one saw or altered the question; protective DNS prevents the right response from leading to a wrong destination; and SOC monitoring turns every query into a detection signal. Together, these controls close the integrity and confidentiality gaps that classic DNS left open — and make DNS an ally of the defense, not just a risk vector.
How Decripte helps
Decripte is a B2B cybersecurity company serving organizations from 1 to more than 100,000 employees. We implement protective DNS, DNSSEC validation, resolver hardening, DNS monitoring integrated with the SOC/SIEM and incident response for DNS hijacking and tunneling — always sized to the scale and risk appetite of each client. Whether you are a lean team or a global operation, DNS security can be one of the highest-return controls you activate.
Start understanding your exposure today: start for free through our Intelligence Center or explore the plans that grow with your organization.