DNS Security Explained

Why DNS Security Matters

DNS is the internet's phone book — it translates human-readable domain names into IP addresses. Nearly every internet connection starts with a DNS query. Because traditional DNS operates in plaintext over UDP port 53, it is vulnerable to eavesdropping (anyone on the network can see which domains you're visiting), tampering (responses can be modified in transit), and poisoning (fake records can be injected into caches).

A successful DNS attack is particularly dangerous because it operates invisibly to the user. The user types a legitimate URL, the browser shows no obvious warning, and they are seamlessly delivered to an attacker-controlled server. Credentials, sensitive data, and malware delivery can all follow.

DNS Attack Types

DNSSEC — DNS Security Extensions

DNSSEC adds cryptographic digital signatures to DNS records so that resolvers can verify that responses are authentic and have not been tampered with in transit. It does not encrypt DNS queries — it only validates their authenticity. DNSSEC creates a chain of trust starting from the DNS root zone.

DNS over HTTPS (DoH) and DNS over TLS (DoT)

While DNSSEC validates the authenticity of DNS responses, it does not encrypt them. Traditional DNS over UDP/53 is visible to anyone on the network — ISPs, network administrators, and on-path attackers can see every domain you query. DoH and DoT solve this by encrypting the DNS query and response.

Split-Horizon DNS

Split-horizon DNS (also called split-brain DNS or split-view DNS) uses different DNS answers for the same domain depending on who is asking. Internal users querying from inside the corporate network receive internal IP addresses (or hostnames of internal servers). External users querying from the internet receive public IP addresses.

DNS Security Comparison Table

Exam Scenarios

DNS Record Types and Security Relevance

Understanding DNS record types is both a Network+ exam requirement and essential context for understanding why DNS security controls like DNSSEC, SPF, DKIM, and DMARC work the way they do — since all of them rely on specific DNS record types.

A record: maps a hostname to an IPv4 address. The most common DNS record type. When you look up google.com, the A record returns its IPv4 address. AAAA record: maps a hostname to an IPv6 address. Both A and AAAA records are targeted by DNS spoofing attacks — an attacker who can forge a response can redirect traffic for any hostname.

MX record: specifies which mail servers accept email for a domain. The value is a hostname (which must itself have an A/AAAA record) and a priority number — lower number = higher priority. When another mail server wants to deliver email to user@company.com, it queries the MX record for company.com. MX records are directly relevant to email security — misconfigured MX records can cause email to be delivered to the wrong server.

TXT record: stores arbitrary text data. This is the mechanism used by SPF (specifies authorized mail server IPs), DKIM (publishes public keys for signature verification), DMARC (specifies enforcement policy), and various domain ownership verification methods. TXT records are critical for email security but are also used for other purposes — Google Search Console verification, Microsoft 365 tenant verification, and general domain attribute declarations. An attacker with DNS zone control can modify TXT records to redirect email traffic or invalidate security controls.

PTR record: reverse DNS — maps an IP address back to a hostname. Used for logging (recording the hostname associated with an IP in log files), email server validation (receiving mail servers check if the sending IP's PTR record matches the claimed domain), and network troubleshooting. Absence of a PTR record for a mail server IP is a spam signal — legitimate mail servers have matching forward and reverse DNS.

NS record: specifies the authoritative name servers for a domain. Compromising or hijacking NS records is a powerful attack — redirect the NS records to your own servers and you control all DNS for the domain. SOA record: Start of Authority — contains administrative information about the DNS zone including the primary name server, zone administrator email, and timing parameters. One SOA per zone.

DNS Sinkholing

DNS sinkholing is a defensive technique where a DNS server is configured to return a false IP address for known malicious domains — redirecting the connection to a controlled server (the "sinkhole") instead of the attacker's infrastructure. When malware-infected machines attempt to contact their command-and-control (C2) server, the DNS sinkhole intercepts the lookup and returns the sinkhole's IP address. The connection goes to the sinkhole instead of the real C2 server, effectively isolating the malware from its controller.

From a security operations perspective, sinkholes provide two benefits: they neutralize active malware (infected machines cannot receive commands or exfiltrate data) and they identify infected hosts (the sinkhole server logs all connection attempts, revealing which internal IP addresses are querying malicious domains). This is valuable for incident response teams trying to identify compromised systems. DNS sinkholes are a core feature of enterprise DNS security platforms such as Cisco Umbrella, Infoblox, and Palo Alto DNS Security.

DNS Blocklists (DNSBL)

A DNS Blocklist (DNSBL), formerly called a DNS Blacklist, is a database of known malicious or spam-associated IP addresses and domains that is queryable via DNS. Mail servers have used DNSBLs for spam filtering for decades — when receiving an email, the mail server queries a DNSBL to check whether the sending server's IP is listed as a known spam source. If it is, the email is rejected or scored as spam.

Modern DNS security extends this concept from email to all DNS traffic. Threat intelligence feeds populate blocklists of known malware distribution domains, phishing sites, botnet C2 servers, and other malicious infrastructure. DNS resolvers configured with these feeds automatically block queries to listed domains, returning an NXDOMAIN response or sinkhole IP instead of resolving the request. This provides automatic protection at the DNS layer for all devices on the network, regardless of whether they have endpoint security software installed — including IoT devices that cannot run traditional antivirus.

DNS Tunneling

DNS tunneling is an attack technique (and occasionally a legitimate tool) that encodes arbitrary data into DNS queries and responses to create a covert communication channel that bypasses traditional network controls. DNS is typically allowed through firewalls because it is essential for internet access — attackers exploit this by encoding data in DNS query names and TXT records, creating a bidirectional communication channel hidden within what appears to be normal DNS traffic.

A malware infection might use DNS tunneling to exfiltrate data by encoding file contents into DNS lookup queries: aGVsbG8gd29ybGQ.attacker-controlled.com where the subdomain contains base64-encoded data. The attacker's authoritative DNS server receives these queries and decodes the data. Responses encode commands back to the malware using DNS TXT records. Because many organizations permit DNS traffic with minimal inspection, DNS tunneling can persist undetected for extended periods.

Detection methods for DNS tunneling include monitoring for abnormally long DNS query names (legitimate queries are rarely more than a few dozen characters), high volumes of queries to a single domain, unusual TXT record responses, and domains with high Shannon entropy in their subdomains (indicating encoded binary data). DNS security platforms and SIEM rules specifically watch for these patterns.

Recursive vs Authoritative DNS Servers

Understanding the distinction between recursive and authoritative DNS servers is a fundamental networking concept tested on Network+ and relevant to DNS security discussions.

Authoritative DNS servers hold the actual DNS records for a zone — they are the canonical source of truth for a domain's IP addresses, mail records, and other records. When you register a domain and publish DNS records through your registrar or DNS hosting provider (Route 53, Cloudflare DNS), you are configuring authoritative servers. They only answer queries about zones they are authoritative for.

Recursive (or resolver) DNS servers answer client queries by hunting through the DNS hierarchy on the client's behalf. When your laptop queries its configured DNS server (typically provided by DHCP from your ISP or IT department), that server is a resolver. If it doesn't have the answer cached, it queries root servers, then TLD servers, then the authoritative servers, then returns the answer to your client and caches it. Corporate DNS servers, ISP resolvers, and public resolvers like 8.8.8.8 (Google) and 1.1.1.1 (Cloudflare) are all recursive resolvers.

Security implications: DNS cache poisoning attacks target recursive resolvers — if an attacker can poison the cache of a widely-used resolver, many clients are affected. DNSSEC prevents cache poisoning by validating that records came from the authoritative server. Open resolvers (recursive resolvers that answer queries from any IP on the internet) are used in DNS amplification DDoS attacks — attackers spoof the victim's IP in DNS queries to open resolvers, which send large responses to the victim's IP, overwhelming it with traffic.

Related Topics