Secure DNS: DNSSEC and DNS over HTTPS (DoH)

The Domain Name System (DNS) translates human-readable domain names into IP addresses. Designed in the 1980s, DNS was built without security — queries and responses travel over UDP/TCP port 53 in plaintext with no authentication. This creates two major vulnerabilities: DNS cache poisoning (injecting forged DNS responses to redirect users to malicious servers) and DNS eavesdropping (observing which domains a user queries reveals their browsing activity). Two standards address these: DNSSEC prevents forgery, and DNS over HTTPS (DoH) prevents eavesdropping.

DNS cache poisoning (Kaminsky attack) exploits the DNS protocol's lack of authentication. A resolver sends a query to an authoritative DNS server and caches the response for the TTL duration. An attacker who can guess the transaction ID (16-bit, predictable) and source port (used as additional entropy since RFC 5452) can send forged responses that the resolver caches, redirecting all users who query that resolver to the attacker's server. Once the cache is poisoned, users are directed to fake servers even though they typed the correct domain. DNSSEC prevents this by digitally signing DNS responses.

DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that responses came from the legitimate zone authority and have not been tampered with. DNSSEC introduces new record types: RRSIG (resource record signature, the actual signature over a record set), DNSKEY (the public key used to verify signatures), DS (delegation signer, links parent and child zone keys), and NSEC/NSEC3 (authenticated denial of existence — proves a name does not exist). DNSSEC creates a chain of trust from the root zone (signed by ICANN) down through TLD and authoritative zones.

DNSSEC uses two types of signing keys. The Zone Signing Key (ZSK) signs the individual DNS record sets (RRSIGs) and is rotated frequently (monthly or quarterly) for operational agility. The Key Signing Key (KSK) signs the DNSKEY record set, providing the anchor of trust for the zone. The KSK is rotated less frequently (annually) because the parent zone must be updated with the new DS record whenever the KSK changes — a process requiring coordination. The KSK verifies the ZSK; the ZSK signs the data. This two-layer structure balances security (frequent ZSK rotation) against operational burden (infrequent KSK rotation).

DNSSEC has important limitations. It does not encrypt DNS queries — it only signs responses for integrity. An eavesdropper can still see all DNS queries, just cannot forge responses. Zone enumeration: NSEC records (which prove non-existence) allow attackers to walk the zone and enumerate all domain names within it; NSEC3 mitigates this with hashed names but is not perfect. Operational complexity: key management, signature expiry, and parent zone coordination create significant operational overhead. DNSSEC adoption remains incomplete — many TLDs and registrars support it, but many organizations have not deployed it.

DNS over HTTPS (DoH) encrypts DNS queries inside HTTPS (RFC 8484), hiding query contents from network observers. Queries go to a DoH-capable resolver at a standard HTTPS URL, making DNS traffic indistinguishable from other HTTPS traffic. This prevents ISPs, employers, and on-path attackers from seeing which domains a user queries — addressing the privacy gap that DNSSEC leaves. However, DoH shifts trust from the network's DNS resolver to the DoH provider (typically Google 8.8.8.8, Cloudflare 1.1.1.1, or the organization's own DoH resolver). DoH is now supported natively in most major browsers.

DNS over TLS (DoT) (RFC 7858) encrypts DNS queries using TLS over a dedicated TCP port 853, rather than tunneling through HTTPS. DoT provides the same privacy benefits as DoH — hiding query content from eavesdroppers — but is easier for network administrators to identify and filter (port 853 vs port 443). This is a double-edged sword: DoT is visible and can be blocked by enterprise firewalls, whereas DoH is harder to block without affecting general HTTPS traffic. Stub resolvers (OS-level) more commonly use DoT; browsers more commonly use DoH.

Encrypted DNS creates a challenge for enterprise environments that depend on DNS-based filtering and sinkholes. When browsers use external DoH resolvers, internal DNS controls are bypassed. Enterprise countermeasures: deploy an internal DoH/DoT resolver (Cisco Umbrella, Pi-hole with DoH) and configure all devices to use it; block external DoH resolver IPs at the firewall (Google 8.8.8.8, Cloudflare 1.1.1.1) on port 443; Group Policy to disable browser-level DoH on managed endpoints; and transparent proxy rules that intercept DNS-over-TLS on port 853. The goal: route all DNS through the controlled resolver without blocking encrypted DNS entirely.

A complete DNS security strategy combines multiple controls. DNSSEC for your authoritative zones prevents cache poisoning of your domain. DNS-based filtering (Cisco Umbrella, Cloudflare Gateway) blocks malicious domains at the resolver level. DoH/DoT to a controlled resolver provides query privacy without losing filtering visibility. DNS logging to the SIEM captures all queries for threat hunting — DNS logs reveal C2 traffic, data exfiltration via DNS tunneling, and domain generation algorithm (DGA) activity from malware. DNS telemetry is one of the highest-value security data sources available.

DNS tunneling encodes data inside DNS queries and responses to exfiltrate data or establish C2 channels through networks where other outbound traffic is blocked. Tools like iodine, DNScat, and dnscat2 encode payloads in subdomain labels (query for EXFILTRATEDDATA.evil.com) or TXT records. Detection: unusually long DNS query names (>100 characters), high query volume from a single host, queries for non-existent parent domains, unusual record types (TXT, NULL), and entropy analysis of domain labels (encoded data has high Shannon entropy). DNS security analytics platforms automatically flag tunneling patterns.

DNS Response Policy Zones (RPZ) allow DNS resolvers to apply local override policies to DNS responses — essentially creating a local sinkhole at the resolver level without modifying global DNS infrastructure. When a client queries for a known-malicious domain, the RPZ policy returns NXDOMAIN, a redirect to a sinkhole IP, or a passthrough response. RPZ feeds are available from threat intelligence providers (Spamhaus, SURBL) and can be imported directly into BIND or Unbound resolvers. RPZ is a powerful defensive tool because it applies filtering at the DNS layer for all devices on the network without any client-side configuration.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: DNSSEC adds cryptographic signatures to DNS records using KSK/ZSK key pairs to prevent cache poisoning but does not encrypt queries, DNS over HTTPS (DoH) encrypts DNS queries inside HTTPS to prevent eavesdropping but creates enterprise filtering bypass risks, and DNS tunneling encodes data in DNS queries and can be detected through query length, volume, and entropy analysis. Next up we explore IPsec, VPN protocols, and remote access security.