DNSSEC and DNS over HTTPS are often discussed as rival ways to "secure DNS", but they protect different properties on different legs of a lookup, so choosing one instead of the other leaves a known attack open. DNSSEC lets a validating resolver prove that an answer came unaltered from the zone owner. DNS over HTTPS (DoH) encrypts the query between a client and its resolver so on-path observers cannot read or change it. Neither does the other's job. This guide sets out the threats each addresses, what each leaves exposed, the enterprise visibility problem DoH creates, deployment failure modes such as key rollover and resolver bypass, and a policy per network zone. It is for network, DNS and security architects. For signing and validation detail, see the DNSSEC Deployment Guide; for client settings, see the Encrypted DNS Enterprise Guide.
Key takeaways
- Integrity versus confidentiality. DNSSEC provides origin authentication and integrity of DNS data; DoH provides confidentiality and integrity of the transport between client and resolver. RFC 7858 calls DNSSEC and encrypted DNS transport independent and complementary.
- Different legs of the lookup. DoH protects the stub to resolver hop; DNSSEC protects the data end to end from the authoritative zone to whoever validates it, usually the recursive resolver.
- DoH trusts the resolver completely. An encrypted channel to a resolver that has been poisoned, compromised or is simply not validating delivers a forged answer safely encrypted.
- DNSSEC leaks every query. Signed answers travel in clear text unless the transport is encrypted, so anyone on path still sees which names you look up.
- The enterprise pattern is both, under your control. Validate DNSSEC at your own resolvers, offer encrypted transport from clients to those resolvers, and stop clients from taking DoH to outside resolvers that bypass your security controls.
The short answer
DoH does not replace DNSSEC, and DNSSEC does not replace DoH. Deploy DNSSEC validation on every recursive resolver you operate and sign the zones you own where your registrar and DNS provider support it. Offer encrypted DNS (DoH, DNS over TLS or DNS over QUIC) from managed clients to your own resolvers, so you gain transport privacy without losing filtering and logging. Block or disable DoH to resolvers you do not control on managed networks and devices. RFC 9364 (BCP 237) states that DNSSEC is the best current practice for origin authentication of DNS data and that no Standards Track alternative exists; encrypted transport does not change that.
What each one is
DNSSEC
DNSSEC adds digital signatures to DNS data. Zone owners sign record sets (RRSIG records) with keys published in DNSKEY records; the parent zone publishes a DS record that vouches for the child's key, building a chain of trust from the root zone. A validating resolver checks the chain and returns an answer only if it validates. RFC 9364 lists the core specifications as RFC 4033, 4034 and 4035, updated by RFC 6840. A failed validation produces SERVFAIL, and RFC 8914 gives resolvers Extended DNS Error code 6, DNSSEC Bogus, to say why.
DNS over HTTPS
RFC 8484 (Proposed Standard, October 2018) carries DNS messages in wire format inside HTTPS using the application/dns-message media type, to a URI template the client obtains from configuration. It encrypts and authenticates the channel between the client and the resolver. Its siblings are DNS over TLS (RFC 7858, TCP port 853) and DNS over QUIC (RFC 9250, UDP port 853). RFC 8310 defines a Strict Privacy profile, where the client requires an encrypted and authenticated connection and fails hard otherwise, and an Opportunistic Privacy profile, where it encrypts when it can and falls back to clear text when it cannot.
Side-by-side comparison
| Property | DNSSEC | DNS over HTTPS |
|---|---|---|
| Security goal | Origin authentication and data integrity | Confidentiality and integrity of the client to resolver channel |
| Protects against | Forged answers, cache poisoning, tampering anywhere between zone and validator | Eavesdropping and tampering on the local network and access path |
| Leg of the lookup | End to end, authoritative zone to validating resolver (or client, if it validates) | Stub client to recursive resolver only |
| Who must act | Zone owners sign; resolver operators validate; registrars publish DS | Client (browser or OS) and resolver operator |
| Hides query contents | No | Yes, from on-path observers; the resolver still sees everything |
| Trusts the resolver | Not for data authenticity, if the client validates; yes in the usual design where the resolver validates | Completely: the resolver can return anything |
| Typical failure mode | Validation failures (SERVFAIL) after key rollover or DS mismatch: the domain goes dark for validating users | Silent bypass of enterprise resolvers; fallback to clear text in opportunistic mode |
| Ports | Standard DNS, port 53 (larger responses, more TCP) | TCP 443, indistinguishable from other HTTPS by port |
| Status | Best Current Practice (RFC 9364, BCP 237) | Proposed Standard (RFC 8484) |
Threat model: what each addresses and leaves exposed
| Threat | DNSSEC | DoH | What closes the gap |
|---|---|---|---|
| Off-path cache poisoning of a recursive resolver | Detected by validation for signed zones | No effect: the poisoned answer is served over the encrypted channel | DNSSEC validation; RFC 5452 hardening for unsigned zones |
| On-path tampering on the local network (rogue Wi-Fi, ATT&CK T1557 Adversary-in-the-Middle) | Detected only if the client itself validates | Prevented for the encrypted hop | Encrypted transport to a trusted resolver; client validation where supported |
| Passive surveillance of which names a user looks up | No protection | Protected from on-path observers | Encrypted transport; resolver logging policy |
| Compromised or malicious resolver | Detected only if validation happens downstream of that resolver | No protection | Use resolvers you control or trust contractually |
| Hijack of the domain at the registrar or authoritative provider (T1584.002 DNS Server) | No protection: the attacker can sign or remove DS | No protection | Registrar lock, MFA on registrar and DNS provider accounts, change monitoring |
| Malicious domain registered legitimately | No protection: it may be validly signed | No protection | Protective DNS and threat intelligence |
| C2 and data exfiltration over DNS (T1071.004) | No effect | Makes it harder to see when it uses outside DoH resolvers | Force DNS through monitored resolvers; DNS traffic analysis |
NSA and CISA guidance on protective DNS makes the same point from the other direction: DNSSEC and encrypted transport protect record integrity and query privacy, but neither addresses compromised upstream infrastructure or maliciously registered domains. Two of the most damaging DNS attack classes, registrar account takeover and malicious registrations, sit outside both technologies. See the Authoritative DNS and Registrar Account Security Guide.
Cache poisoning: why encryption is not the fix
RFC 5452 describes how an attacker races a forged answer to a recursive resolver, which accepts a response when the question, query ID, addresses and port all match. Its countermeasures (unpredictable query IDs across the full 16-bit range, source port randomisation, strict matching, in-domain filtering, TCP retry when spoofing is suspected) raise the cost of guessing, and the RFC itself calls them complementary to cryptographic protection, pointing to DNSSEC. DoH between a laptop and the resolver does nothing for the resolver's own upstream queries to authoritative servers, which is where off-path poisoning happens.
Local tampering: why signatures alone are not the fix
Most clients do not validate DNSSEC themselves; they trust the "authenticated data" result from their resolver. On a hostile local network, an attacker between the laptop and the resolver can alter that answer in clear text. Encrypted transport closes that hop. Without it, DNSSEC protects the resolver's cache but not the last metre to the user.
Enterprise visibility loss with DoH
Enterprise DNS is a security control as well as a naming service: protective DNS blocks, split-horizon internal names, query logging for detection and incident response. When a browser or application sends DoH to an outside resolver, all of that is bypassed, and because the traffic runs on TCP 443 it looks like any other HTTPS connection. RFC 8484 itself notes that sharing a connection with other HTTPS traffic makes DNS traffic analysis harder for on-path devices, and NSA and CISA list encrypted DNS to alternative resolvers as a way malware and applications evade protective DNS.
- Lost controls: protective DNS blocks, internal name resolution (which may break or leak internal names to an outside resolver), DNS-based detections in the SIEM.
- Lost evidence: during an incident, queries sent to an outside DoH resolver never reach your logs. See the DNS Logging and Detection Guide.
- The answer is ownership, not prohibition of encryption: run encrypted DNS to your own resolvers so you keep privacy on hostile networks and keep control.
Mechanisms to keep encrypted DNS on your resolvers
| Mechanism | What it does | Notes |
|---|---|---|
| Windows DNS client policy "Configure DNS over HTTPS (DoH) name resolution" | Options Allow DoH, Prohibit DoH, Require DoH, under Computer Configuration, Administrative Templates, Network, DNS Client | Microsoft warns against Require DoH on domain-joined machines because the Windows Server DNS service does not serve DoH and AD DS depends on DNS; it suggests IPsec for encrypting AD DNS traffic |
| Windows known DoH server list | DoH is used only when the configured server is on the list; add your resolver with its template and disable UDP fallback | Defaults include Cloudflare, Google and Quad9 addresses (listed alphabetically) |
Firefox canary domain use-application-dns.net | If your resolver returns NXDOMAIN, SERVFAIL or no A or AAAA records, Firefox disables default DoH | Does not apply to users who enabled DoH themselves; use managed browser policy as well |
| Discovery of Designated Resolvers (RFC 9462) | Clients query _dns.resolver.arpa SVCB records on the plain resolver and upgrade to the encrypted resolver it designates | Verified discovery needs the resolver's IP address in the certificate; opportunistic discovery applies to private addresses only when the IP is the same |
| Network egress controls | Block outbound 53 and 853 except from resolvers; block known public DoH endpoints at the proxy | Endpoint lists change; pair with endpoint policy |
Deployment failure modes
DNSSEC
- Key rollover mistakes: publishing a new key signing key without the parent's DS record updated, or removing the old DS too early, makes the zone bogus and unreachable for every validating resolver. Automate with CDS and CDNSKEY where the parent supports it, as covered in the DNSSEC Deployment Guide.
- Trust anchor drift on resolvers: ICANN reports that the root zone key KSK-2024 began signing the root zone on 11 October 2026 and that the rollover completed as planned, while noting reports of issues affecting a limited number of systems. Resolvers with manually configured, stale trust anchors are the ones that fail in such events; check that automatic trust anchor updates are working.
- Turning off validation to "fix" an outage: disabling validation globally removes protection for every signed zone. Use a negative trust anchor for the single broken domain, time-limited.
- Low uptake masking value: RFC 9364 records that, when it was written, fewer than 10% of website domain names were signed and about a third of queries to recursive resolvers were validated. Validation protects you only for signed zones, so sign your own.
DoH
- Resolver bypass: browsers in automatic DoH mode on unmanaged policy use outside resolvers and skip protective DNS.
- Silent fallback: opportunistic modes fall back to clear text with no warning. Microsoft notes that the "Encrypted preferred, unencrypted allowed" option gives no notification when it falls back.
- Breaking Active Directory: forcing DoH-only on domain members when domain controllers serve plain DNS stops name resolution.
- Encrypting to a non-validating resolver: privacy improves, integrity does not. Check that the resolver behind your DoH endpoint validates DNSSEC.
Policy per network zone
| Zone | DNSSEC | Encrypted DNS | Rationale |
|---|---|---|---|
| Managed laptops off network | Validation at your resolver or roaming service | Required to your resolver (Strict profile where the client supports it) | Hostile networks: transport privacy matters most here |
| Corporate LAN and Wi-Fi | Validation on internal resolvers | Offered via designated resolver; outside DoH blocked | Keep filtering and logging; encryption optional on trusted segments |
| Domain controllers and AD clients | Validation on forwarders to the internet | Plain DNS internally, IPsec where encryption is required | AD dependency on DNS; avoid Require DoH |
| Data centre and cloud workloads | Validation on resolvers or cloud resolver service | Optional; restrict egress to approved resolvers | Workloads should never pick their own resolver |
| Guest and BYOD | Validation on the guest resolver | Cannot be enforced on devices; filter at network edge | Accept device choices; protect the corporate network |
| Public authoritative zones you own | Sign, with monitored rollovers | Not applicable | Lets every validating resolver detect forgeries of your names |
Decision guidance
- Small organisations using a managed resolver or protective DNS service: confirm the service validates DNSSEC (NSA and CISA list DNSSEC validation and DoH or DoT support among the capabilities to look for), use its roaming client for encrypted transport, and turn on DNSSEC signing at your DNS host if it offers one-click signing.
- Large organisations running their own resolvers: validate everywhere, publish designated encrypted resolvers, enforce browser and OS policy, block outside DoH, and sign public zones with automated rollover.
- Privacy-sensitive users (journalists, executives travelling): encrypted DNS in Strict mode to a trusted resolver matters more than local validation.
- If you can only do one thing this quarter: turn on validation at your resolvers and block DoH to outside resolvers. Validation protects every user immediately; closing bypass keeps your other DNS controls working.
Worked scenario
A 1,500-person firm runs internal resolvers forwarding to a protective DNS service. Validation is off because of a past outage, and browsers are on default DoH settings. An investigation into a phishing incident finds no DNS logs for the victim's laptop: the browser had resolved through a public DoH resolver. The remediation plan: enable validation on internal resolvers with a negative trust anchor process for broken domains; set the Windows DoH policy to use the company resolver with UDP fallback disabled for roaming laptops; push browser policy to use the company resolver; answer the canary domain with NXDOMAIN; block outbound 853 and known DoH endpoints; publish designated resolver records. A month later, DNS coverage reaches all managed laptops and the SOC can again see the queries that matter.
Detection and measurement
- Validation rate: share of resolver responses with the authenticated data flag for signed zones, and count of DNSSEC Bogus failures by domain.
- Outside DoH and DoT attempts: connections to known public DoH endpoints and to port 853 not destined for your resolvers, per week, by host.
- Encrypted coverage: share of managed device queries arriving over encrypted transport at your resolvers.
- Fallback events: clients falling back to clear text from roaming networks.
- Own zone health: days to next scheduled key rollover, DS and DNSKEY consistency checks, and alerts on unexpected DS changes at the parent.
Common failure patterns
- Treating DoH as "DNS security done": encrypted queries to a non-validating or uncontrolled resolver.
- Signing zones but never monitoring rollovers: the first missed DS update takes the domain offline for validating users.
- Disabling validation globally after one failure instead of a scoped negative trust anchor.
- Leaving browser DoH on vendor defaults on managed devices, so filtering and logging silently stop.
- Forgetting the registrar: DNSSEC and DoH both fail if an attacker controls the registrar account.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-20 Secure Name/Address Resolution Service (Authoritative Source) | Signing your zones |
| NIST SP 800-53 Rev. 5 | SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver) | Validation on resolvers |
| NIST SP 800-53 Rev. 5 | SC-22 Architecture and Provisioning for Name/Address Resolution Service; SC-8 Transmission Confidentiality and Integrity | Resolver architecture; encrypted DNS transport |
| NIST CSF 2.0 | PR.DS-02; DE.CM-01 | Data in transit protection; monitoring network services |
| NIST SP 800-81 Rev. 3 | Secure DNS Deployment Guide (final, March 2026) | Current NIST guidance on DNS protocol and infrastructure security. See the NIST SP 800-81 Rev. 3 Secure DNS Deployment Guide |
| MITRE ATT&CK | T1557 Adversary-in-the-Middle; T1071.004 DNS; T1584.002 DNS Server | Techniques each control does or does not address |
Practitioner checklist
- DNSSEC validation is enabled on every recursive resolver you run or buy, with automatic trust anchor updates.
- A documented, time-limited negative trust anchor process exists for broken third-party domains.
- Your public zones are signed, with monitored and preferably automated key rollovers.
- Managed clients use encrypted DNS to your resolvers when off network, with fallback behaviour decided deliberately.
- Browser and OS DoH settings are managed; the canary domain is answered where Firefox is used.
- Outbound 53, 853 and known public DoH endpoints are blocked except from your resolvers.
- Domain controllers and AD clients are excluded from DoH-only policy.
- Registrar and DNS provider accounts have MFA, registry lock where available and change alerts.
Standards and references
- IETF: RFC 9364, DNS Security Extensions (DNSSEC)
- IETF: RFC 8484, DNS Queries over HTTPS (DoH)
- IETF: RFC 7858, Specification for DNS over Transport Layer Security (TLS)
- IETF: RFC 8310, Usage Profiles for DNS over TLS and DNS over DTLS
- IETF: RFC 5452, Measures for Making DNS More Resilient against Forged Answers
- IETF: RFC 9462, Discovery of Designated Resolvers
- NIST: SP 800-81 Rev. 3, Secure Domain Name System (DNS) Deployment Guide
- Microsoft: Secure DNS client over HTTPS (DoH)
Related NHI Mgmt Group resources: DNSSEC Deployment Guide, Encrypted DNS Enterprise Guide, DNS Security Guide, Protective DNS Guide, DNS Filtering vs Secure Web Gateway.