# DNS Security
DNS (Domain Name System) security encompasses the controls that protect the DNS infrastructure from abuse, prevent DNS-based attacks, and use DNS telemetry as a detection and enforcement layer. DNS translates human-readable domain names (cda.security) into IP addresses (the numerical addresses that network devices use to communicate). Every web request, email delivery, application connection, and cloud API call begins with a DNS query.
This ubiquity makes DNS both a critical dependency and a critical attack surface. If DNS fails, nothing works: no web access, no email, no cloud applications, no SaaS. If DNS is compromised, the attacker controls where traffic goes: users who type the correct URL arrive at the attacker's server. If DNS is monitored, it becomes one of the most valuable detection data sources available: nearly every malware callback, C2 communication, and data exfiltration attempt involves DNS resolution.
DNS was designed in 1983 for a trusted network. It has no built-in authentication, encryption, or integrity verification in its original specification. Every DNS security control that exists today (DNSSEC, DNS-over-HTTPS, DNS filtering, DNS logging) was added after the protocol was already globally deployed. Securing DNS is retrofitting security onto infrastructure that was not designed for it.
DNS spoofing/cache poisoning. The attacker injects fraudulent DNS responses into a recursive resolver's cache, causing the resolver to return an attacker-controlled IP address for a legitimate domain name. Users who query the poisoned resolver are redirected to the attacker's server without their knowledge. The Kaminsky attack (2008) demonstrated that DNS cache poisoning was practically exploitable against most resolvers, accelerating the adoption of DNSSEC.
DNS hijacking. The attacker modifies DNS records at the authoritative level: compromising the registrar account (through credential theft or social engineering), compromising the DNS management interface, or exploiting a vulnerability in the DNS hosting provider. DNS hijacking redirects all traffic for the affected domain to the attacker's infrastructure. The Sea Turtle campaign (2017-2019), attributed to a state-sponsored actor, used DNS hijacking against government and telecommunications targets across the Middle East and North Africa.
DNS tunneling. The attacker uses DNS queries and responses to establish a covert communication channel. Data is encoded in DNS query strings (e.g., exfiltrated-data.attacker-domain.com) and decoded by the attacker's authoritative DNS server. DNS tunneling bypasses most firewalls and proxies because DNS traffic is almost universally permitted. Malware families including SUNBURST (SolarWinds) have used DNS-based communication for C2.
DDoS against DNS. Distributed denial-of-service attacks targeting the organization's authoritative DNS servers. If the DNS servers are overwhelmed, no one can resolve the organization's domain names, making all internet-facing services unreachable. The 2016 Dyn DDoS attack (using the Mirai botnet) disrupted DNS resolution for major websites including Twitter, Netflix, and Reddit by attacking a single DNS provider.
Domain generation algorithms (DGAs). Malware generates pseudo-random domain names algorithmically, registering a subset of them as C2 infrastructure. The malware queries these domains until it finds one that resolves to a live C2 server. DGAs make C2 blocking difficult: blocking one domain does not prevent the malware from generating and querying the next.
Dangling DNS records. DNS records that point to IP addresses or cloud resources no longer controlled by the organization. An attacker who discovers a dangling CNAME record pointing to a decommissioned cloud resource can provision a new resource at that address and serve content under the organization's subdomain (subdomain takeover).
DNSSEC (DNS Security Extensions). Adds cryptographic signatures to DNS records, enabling resolvers to verify that the DNS response is authentic (came from the authorized source) and has not been modified in transit. DNSSEC prevents cache poisoning and spoofing by providing cryptographic proof that the response matches what the zone owner published.
DNSSEC adoption remains incomplete. As of 2024, approximately 30% to 40% of domains globally have DNSSEC-signed zones, though validation by resolvers is more widespread (major public resolvers like Google and Cloudflare validate DNSSEC). The deployment complexity (key management, key rotation, parent-child signing chains) has slowed adoption, particularly for organizations with complex DNS architectures.
DNS filtering (protective DNS). DNS filtering services (Cisco Umbrella, Cloudflare Gateway, Infoblox BloxOne, CISA's Protective DNS for federal agencies) evaluate DNS queries against threat intelligence and category databases before returning responses. Queries for known malicious domains (C2 infrastructure, phishing sites, malware distribution) are blocked at the DNS layer before the connection is established.
DNS filtering is one of the most efficient security controls available because it operates at the earliest possible point in the connection: before the TCP handshake, before any data is exchanged, and before the user reaches the malicious content. Blocking a malicious domain at DNS resolution prevents the entire attack chain that would follow if the connection succeeded.
DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT). Encrypt DNS queries between the client and the resolver, preventing eavesdropping and manipulation of DNS traffic by network intermediaries. DoH encapsulates DNS in HTTPS traffic (port 443). DoT uses a dedicated TLS connection (port 853).
DoH and DoT protect user privacy (ISPs and network operators cannot see which domains the user is resolving) but create a security challenge for organizations: encrypted DNS traffic bypasses DNS-based security controls (filtering, logging) if the client sends queries to an external DoH resolver rather than the organization's managed resolver. Enterprise DNS security requires configuring managed endpoints to use the organization's DNS resolver (which provides filtering and logging) and blocking external DoH/DoT traffic.
DNS logging and monitoring. DNS query logs are among the most valuable data sources for threat detection. Nearly every attack involves DNS: malware resolves its C2 domain, the attacker resolves internal hostnames during discovery, exfiltrated data is tunneled through DNS queries. Logging all DNS queries (internal resolver logs, DNS firewall logs, endpoint DNS telemetry) and ingesting them into the SIEM provides visibility into:
Connections to known malicious domains (IOC matching). Connections to newly registered domains (NRDs, which correlate with malicious infrastructure). DNS tunneling patterns (high query volume, long query strings, unusual record types). DGA patterns (high volumes of NXDOMAIN responses from algorithmically generated names). Internal reconnaissance (queries for Active Directory domain controller SRV records from endpoints that should not be performing AD discovery).
CDA's TID-B01 mission (SIEM Deployment and Tuning) includes DNS query logging as a required log source because it provides detection coverage for techniques that no other log source captures as efficiently.
Domain registration monitoring. Monitor for registration of domains that are visually similar to the organization's primary domains (typosquatting, homoglyph domains, keyword domains). Attackers register these look-alike domains for phishing campaigns, credential harvesting, and brand impersonation. Monitoring services (DomainTools, RiskIQ/Microsoft, MarkMonitor) alert when confusable domains are registered.
Redundant authoritative DNS. Host authoritative DNS with at least two geographically distributed providers. If one provider experiences a DDoS attack or outage, the other continues to resolve the domain. Single-provider DNS is a single point of failure.
Split-horizon DNS. Maintain separate DNS views for internal and external queries. Internal clients resolve internal hostnames (servers, applications, printers) that are not published to the internet. External clients resolve only the organization's public-facing services. Split-horizon prevents information leakage (an attacker cannot discover internal hostnames through external DNS queries).
Response rate limiting (RRL). Configure authoritative DNS servers to limit the rate of responses to identical queries from the same source. RRL mitigates DNS amplification attacks (where the attacker spoofs the victim's IP address and sends queries to the organization's DNS server, which sends the amplified responses to the victim).
DNS is involved in virtually every network communication. A web request resolves the domain. An email delivery resolves the MX record. A cloud API call resolves the endpoint. A malware callback resolves the C2 domain. This universal involvement makes DNS both a universal dependency (disruption affects everything) and a universal detection opportunity (monitoring captures evidence of everything).
DNS filtering blocks threats before the connection is established. A user who clicks a phishing link in an email triggers a DNS query for the phishing domain. If DNS filtering blocks the resolution, the connection never happens. The user sees a block page instead of the phishing form. The credential is not stolen. The attack chain is broken at the earliest possible point.
This early-stage blocking complements later-stage controls (web proxy filtering, endpoint detection) by providing a first-pass filter that reduces the volume of threats that reach deeper inspection layers.
Command-and-control communication is one of the most consequential indicators of compromise. An attacker who has established C2 is actively operating in the environment. DNS-based C2 detection (queries to known C2 domains, DGA patterns, DNS tunneling indicators) provides visibility into active compromises that other detection methods may miss, particularly when the attacker uses encrypted C2 channels that network inspection cannot decrypt.
DNS security sits at the intersection of VSD (Vulnerability and Surface Defense) and TID (Threat Intelligence and Defense) in the Planetary Defense Model. VSD owns the attack surface reduction: DNSSEC deployment, dangling record remediation, authoritative DNS hardening, and domain registration monitoring. TID owns the detection capability: DNS logging, DNS-based threat detection, and C2 identification.
CDA's Continuous Surface Reduction (CSR) methodology applies to DNS: every unnecessary DNS exposure (dangling records, unused subdomains, unprotected authoritative servers) is a surface that CSR identifies and eliminates. CDA's Predictive Defense Intelligence (PDI) methodology applies to DNS monitoring: DNS query logs feed the detection engine that identifies C2 communication, DGA activity, and tunneling attempts before the attacker achieves their objective.
Two TOP missions connect to DNS security:
CDA approaches DNS security with one emphasis: DNS query logging is non-negotiable for any organization CDA assesses. DNS logs provide the earliest and most comprehensive indicator of C2 communication, which is the attack stage where the attacker transitions from access to operations. An organization without DNS query logging has a blind spot at the most critical point in the detection timeline.
Word count: 1,943