DNSSEC, DNS over TLS and DNS over HTTPS: integrity versus privacy

The problem

Classic DNS sends queries and answers in plain text over UDP port 53, with no proof of who sent the answer. This creates two separate weaknesses. Integrity: an attacker who can inject or alter responses (cache poisoning, a rogue Wi-Fi hotspot, a compromised router) can send users to the wrong server. Privacy: anyone on the path, such as a hotspot operator or ISP, can see every name a device looks up. If DNS basics are rusty, read DNS explained first.

Key ideas: DNSSEC

DNSSEC, specified mainly in RFCs 4033 to 4035 (2005), lets zone owners sign their records. New record types carry the signatures and keys:

• DNSKEY holds a zone’s public keys, usually a key-signing key (KSK) and a zone-signing key (ZSK).
• RRSIG holds a signature over a set of records.
• DS, published in the parent zone, contains a hash of the child’s KSK. This links zones into a chain of trust from the root, through the top-level domain, down to the domain.
• NSEC and NSEC3 provide signed proof that a name does not exist.

A validating resolver starts from a configured trust anchor for the root and follows the chain. If a signature fails, it returns a failure (SERVFAIL) instead of a possibly forged answer.

Key ideas: encrypted DNS

• DNS over TLS (DoT), RFC 7858 (2016), wraps DNS in TLS on TCP port 853. It is easy to identify and therefore easy for network administrators to allow or block.
• DNS over HTTPS (DoH), RFC 8484 (2018), sends DNS messages inside HTTPS on port 443, so it blends in with web traffic. Browsers and operating systems support it, often with a choice of resolver.
• DNS over QUIC (DoQ), RFC 9250 (2022), uses QUIC for lower latency.
• Encrypted Client Hello (RFC 9849, March 2026) complements encrypted DNS by hiding the server name inside the TLS handshake, which otherwise leaks it.

What changed recently: the 2026 root KSK rollover

The root zone’s key-signing key is the trust anchor for all of DNSSEC. A new key, KSK-2024 (key tag 38696), was introduced into the root zone in advance, and on 11 October 2026 the root zone starts using only KSK-2024 for signing. Validating resolvers that have not learned the new key, whether by automatic trust anchor updates (RFC 5011) or a software update, will fail to validate and their users could lose DNS resolution. ICANN advises operators to check the trust anchor file (for example bind.keys in BIND, root.key in Unbound) for key tag 38696 and to make sure the resolver can write to its key storage. The previous rollover in 2018 went smoothly, but some long-lived appliances and containers with read-only storage remain a risk.

How practitioners apply it

1. Validate on your resolvers. Modern BIND, Unbound, Knot Resolver and PowerDNS Recursor validate by default or with one setting. Confirm the KSK-2024 trust anchor is present.
2. Sign your zones with your DNS provider’s automated signing and publish the DS record at the registrar. Use modern algorithms such as ECDSA P-256 (algorithm 13).
3. Decide an encrypted DNS policy. In managed networks, offer your own DoT or DoH resolver so devices get privacy without bypassing your security filtering. Use device management to set it.
4. Monitor validation failures and signature expiry; most DNSSEC outages come from expired signatures or mismatched DS records during key changes.

Enterprises face a real design choice with DoH. If browsers send DNS directly to a public resolver over HTTPS, the organisation loses the ability to block known malicious domains and to log lookups for investigations. Many browsers detect managed environments and respect enterprise policy, and some public resolvers honour a "canary" domain that signals the network wants DoH disabled. The cleaner approach is to run or contract an internal resolver that supports DoT or DoH, validate DNSSEC there, apply filtering, and push its address to devices through management tools. Users then get encrypted DNS and the organisation keeps visibility.

Try this: Run dig +dnssec example.com and look for the ad (authenticated data) flag from a validating resolver, then compare with a deliberately broken test domain to see SERVFAIL.

Limitations and open questions

• Uneven DNSSEC adoption. Many large domains are still unsigned, and the last hop from resolver to stub client is often not validated.
• Operational fragility. Signing mistakes cause outages that look like the domain is down.
• Encrypted DNS moves trust to the chosen resolver operator, which sees all queries. It can also bypass enterprise filtering if not managed.
• Post-quantum DNSSEC is an open research problem, because post-quantum signatures are much larger than DNS packets comfortably carry.