DNS Security: How Name Resolution Works and How Attackers Abuse It
How DNS works, the security risks it presents, and practical measures to protect name resolution in your environment.
Last updated Apr 7, 2026Current
Continue your mission
How DNS works, the security risks it presents, and practical measures to protect name resolution in your environment.
The Domain Name System (DNS) translates human-readable domain names (like example.com) into IP addresses (like 93.184.216.34) that computers use to route traffic. Every time you open a website, send an email, or connect to a cloud service, a DNS query happens behind the scenes.
The resolution process involves multiple steps. Your device first checks its local cache. If the answer is not cached, it queries a recursive resolver (typically provided by your ISP or a service like Cloudflare's 1.1.1.1 or Google's 8.8.8.8). The resolver may query root nameservers, TLD (top-level domain) nameservers, and finally the authoritative nameserver for the specific domain. The answer flows back through the chain and is cached at each level.
DNS is fundamental to nearly all internet communication, yet it was designed in the 1980s without security in mind. Queries and responses travel in plaintext by default. There is no built-in mechanism to verify that responses are authentic. This creates multiple attack opportunities.
DNS spoofing/cache poisoning. An attacker sends forged DNS responses to a resolver, causing it to cache an incorrect IP address for a domain. Users who rely on that resolver are then directed to the attacker's server when they try to visit the legitimate domain. The attacker's server might host a phishing page that captures credentials.
DNS tunneling. Attackers encode data within DNS queries and responses to exfiltrate data or establish command-and-control channels. Because DNS is usually allowed through firewalls and not inspected closely, it is an effective covert channel. Tools like dnscat2 and iodine facilitate this.
DNS hijacking. An attacker compromises the domain's registrar account or authoritative DNS server and changes the domain's DNS records to point to attacker-controlled infrastructure. This is more damaging than cache poisoning because it affects all users, not just those using a specific resolver.
Domain generation algorithms (DGAs). Malware uses algorithms to generate large numbers of pseudo-random domain names. The attacker registers a small subset, and the malware tries each one to find an active command-and-control server. This makes blocking C2 communication by domain name extremely difficult.
Typosquatting. Attackers register domains that are slight misspellings of legitimate domains (goolge.com, microsofft.com) to capture traffic from users who mistype URLs.
Protective DNS services filter DNS queries in real time, blocking resolution to known malicious domains. When a device tries to connect to a phishing site, malware C2 server, or newly registered suspicious domain, the protective DNS service returns a blocked response instead of the malicious IP.
Services include Cisco Umbrella, Cloudflare Gateway, Infoblox BloxOne, and the free CISA Protective DNS service for government agencies. Google's 8.8.8.8 and Cloudflare's 1.1.1.1 also offer malware filtering options.
DNS over HTTPS (DoH) encrypts DNS queries within HTTPS traffic. It prevents network observers (including ISPs) from seeing which domains you query. However, it can complicate network monitoring because DNS traffic blends with regular HTTPS traffic.
DNS over TLS (DoT) encrypts DNS queries over a dedicated TLS connection on port 853. It is easier to identify and manage at the network level than DoH.
Both protocols prevent eavesdropping and tampering with DNS queries in transit.
DNS Security Extensions (DNSSEC) add cryptographic signatures to DNS records, allowing resolvers to verify that responses come from the authoritative source and have not been modified. DNSSEC prevents cache poisoning but does not encrypt queries (it provides authenticity, not confidentiality).
Adoption has been slow due to implementation complexity, but it is increasingly expected for government and financial sector domains.
Configure internal DNS resolvers to forward to a protective DNS service. Monitor DNS query logs for anomalies: queries to newly registered domains, unusual query volumes, long subdomain strings (potential tunneling), or queries to known-bad domains. Block direct DNS to external resolvers from endpoints, forcing all queries through your monitored resolvers. Implement DNSSEC for your own domains. Enable DNS logging in your SIEM for correlation with other security events.
CDA Theater missions that address topics covered in this article.
Cryptographic technique that encrypts data while preserving its original format and length, enabling protection without breaking legacy system compatibility.
Guide to HTTP/2 security covering binary framing, HPACK compression attacks, rapid reset vulnerability, stream multiplexing risks, and mitigation strategies.
Explanation of Certificate Transparency framework, covering log servers, Signed Certificate Timestamps, monitoring capabilities, and detection of fraudulent certificates.
Written by CDA Wiki Team
Found an issue? Help improve this article.