DNS translates human-readable names into IP addresses that applications actually connect to. Because every connection begins with a name lookup, compromising DNS redirects users to malicious servers, exfiltrates query data, or poisons caches with fraudulent answers. DNSSEC cryptographically validates response authenticity. Encrypted DNS transport through DoT and DoH protects query confidentiality on local networks. Together these technologies address different threat models — validation without encryption, encryption without validation — and mature deployments implement both where appropriate.
Traditional DNS queries traverse networks in plaintext UDP packets on port 53. Anyone on the path — ISP, coffee shop operator, compromised router — observes which names users resolve. Responses are similarly unprotected, enabling cache poisoning attacks that insert false answers into resolver caches. The Kaminsky attack demonstration in 2008 accelerated DNSSEC deployment, while growing privacy concerns drove encrypted transport standards. Network engineers must understand all three layers to design resolver architecture that satisfies security requirements without breaking legitimate monitoring needs.
DNSSEC Validation
DNSSEC adds cryptographic signatures to DNS records using a chain of trust from the root zone through top-level domains to individual zones. Each zone signs its records with a Zone Signing Key and publishes a Delegation Signer record in the parent zone. Validating resolvers verify signatures before returning answers to clients. A bogus response — one with invalid or missing signatures — is rejected rather than cached.
DNSSEC does not encrypt queries or responses. Signatures travel alongside records in plaintext, and validating resolvers still send queries in the clear unless combined with DoT or DoH. Common misconfigurations include expired signatures after key rollover, broken chain of trust when DS records are not updated in the parent during KSK rollover, and NSEC3 walking concerns in specific zone implementations. Enable DNSSEC validation on recursive resolvers serving your organization — BIND unbound, Windows DNS, and public resolvers like Cloudflare 1.1.1.1 all support validation.
Signing Your Own Zones
Organizations publishing authoritative zones should sign them with DNSSEC to protect their domain from spoofing. The signing process generates ZSK and KSK key pairs, signs all record sets, and publishes DNSKEY, RRSIG, and NSEC or NSEC3 records. Key rollover procedures — especially KSK rollover requiring parent DS record updates — must be documented and practiced. Automated signing through DNS provider platforms simplifies operations for zones hosted externally.
Monitor signature expiration continuously. An expired RRSIG causes validating resolvers to treat the entire zone as bogus, effectively taking the domain offline for security-conscious users. Set alerts thirty days before expiration. DS record mismatches between registrar and authoritative DNS after migration cause validation failures that manifest as intermittent resolution depending on which resolver path a client uses.
DNS over TLS and HTTPS
DNS over TLS encrypts queries between stub resolvers and recursive resolvers on a dedicated port 853. DoT prevents passive eavesdropping on local networks and ISP paths. DNS over HTTPS encapsulates queries within HTTPS requests on port 443, making DNS traffic indistinguishable from web traffic and traversing restrictive firewalls more easily. Both standards encrypt transport but do not inherently validate answer authenticity — combine with DNSSEC validation on the recursive resolver for defense in depth.
Enterprise tension arises when employees use public DoH resolvers that bypass corporate DNS filtering and logging. Browsers with DoH enabled by default may send queries to Cloudflare or Google unless enterprise policy overrides through group policy or MDM configuration. Internal DoH services on corporate resolvers provide encryption without losing visibility — deploy validating resolvers that accept DoH from managed endpoints while blocking unauthorized external resolver IPs at the firewall.
Enterprise Resolver Architecture
Deploy internal recursive resolvers in each major site and cloud VPC rather than relying on ISP resolvers. Configure endpoints to validate DNSSEC, log queries for security analysis, and apply response policy zones blocking known malicious domains. Forward queries to upstream resolvers only for recursion, not as the primary resolution path for internal zones. Split-horizon internal zones remain authoritative on corporate DNS with cloud resolver endpoints forwarding appropriate suffixes.
Network detection and response platforms increasingly ingest DNS logs for threat hunting. Encrypted DNS to internal resolvers preserves this visibility while protecting query privacy on untrusted access networks. Guest WiFi should use resolvers with RPZ filtering but without access to internal zone data. IoT networks benefit from DNS filtering blocking DGA domains common in botnet command and control.
Deployment Considerations
Test applications for DNSSEC incompatibility — some legacy middleware performs its own resolution without validation and breaks when authoritative servers return larger DNSSEC-signed responses that exceed buffer sizes. EDNS0 buffer size issues cause truncation and TCP fallback that poorly implemented clients mishandle. QUIC and HTTP/3 adoption increases reliance on HTTPS-based services where DNS interception was already difficult; encrypted DNS completes the privacy picture for naming.
Document your DNS security architecture: which resolvers validate DNSSEC, which zones are signed, how DoH is enforced on managed devices, and what logging retention applies. DNS is the most underrated attack surface in enterprise security — protecting it with validation and encryption closes vulnerabilities that have enabled some of the most consequential internet attacks in the past two decades.
Incident Response Considerations
When investigating malware infections, DNS query logs reveal command-and-control domain lookups even when IP traffic is encrypted. Encrypted DNS to internal resolvers preserves this visibility; encrypted DNS to external public resolvers may bypass corporate logging depending on client configuration. Incident response playbooks should document how to obtain DNS evidence for endpoints using DoH and the legal process required when logs reside with external providers.
DNSSEC validation failures during key rollover require rehearsed procedures. Practice KSK rollover in staging zones before production events. Maintain communication channels with parent zone operators for DS record updates. A failed rollover taking a domain offline for validating resolvers is a self-inflicted outage as damaging as any external attack.
Split-horizon DNS combined with DNSSEC and DoH creates complex resolver chains that confuse troubleshooting. Document the complete resolution path for each client type: managed laptop using internal DoH, guest device using open resolver, server using local BIND. During outages, test each path independently rather than assuming a single resolver architecture serves all populations.