Support Library
DNSSEC vs DoH
DNSSEC signs the records; DoH encrypts the hop to your resolver. What each protects, what it does not, and why you want both.
The short answer
DNSSEC and DNS over HTTPS solve different problems and work best together. DNSSEC signs the records themselves, so a resolver can prove an answer came unchanged from the zone owner, however many caches it passed through. DoH (and DoT and DoQ) encrypts the connection between a client and its resolver, so nobody on that network path can read or alter the queries. DNSSEC gives integrity without privacy; DoH gives privacy and integrity for one hop only.
| DNSSEC | DoH / DoT / DoQ | |
|---|---|---|
| Protects | The data, end to end from zone to validator | The transport between client and resolver |
| Stops | Forged or altered answers, including cache poisoning of the resolver | Eavesdropping and tampering on the local network or by the ISP |
| Does not stop | Anyone reading which names you look up | A resolver that lies, or a forged answer the resolver itself received |
| Set up by | The domain owner (sign the zone, publish DS) and the resolver (validate) | The client or OS and the resolver operator |
| Covers the resolver to authoritative hop | Yes | No; that hop is usually plain DNS |
| Standards | RFC 4033 to 4035 | RFC 8484 (DoH), RFC 7858 (DoT), RFC 9250 (DoQ) |
Why one does not replace the other
With DoH alone, you trust your resolver completely. If the resolver was poisoned, or an attacker answered its upstream queries, it will hand you the forged record over a perfectly encrypted connection. With DNSSEC alone, the answer is verifiable but travels in clear text, so your ISP or anyone on the Wi-Fi can see every name you look up, and can still block or drop answers.
Most clients do not validate DNSSEC themselves. They rely on the resolver to validate and to set the AD flag, which only means something if the path to the resolver is trustworthy. Encrypting that path with DoH or DoT is what makes the resolver's AD flag worth believing.
Checking each
| Check | Command |
|---|---|
| Is the domain signed and anchored? | dig +short example.com DS |
| Does the resolver validate it? | dig @1.1.1.1 example.com A and look for ad in the flags |
| Does DoH answer from here? | curl -s -H "accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=example.com&type=A" |
| DoH with dig | dig +https @1.1.1.1 example.com A (BIND 9.18 and later) |
See testing DNS over HTTPS and DoH vs DoT vs DoQ for the transport side.
What to do
- Domain owners: sign your zone and publish the DS. DoH on the user's side does nothing for the integrity of your records.
- Network and endpoint owners: use a validating resolver, and reach it over DoH or DoT where your policies allow.
How DNS Panopticon helps
Domain Visualizer uses both. Its lookups travel over DoH to a public resolver, with the DNSSEC OK bit set, and it reads the AD flag in the reply to report whether your domain's DNSSEC validated. It reports on your domain's DNSSEC only; it cannot tell you whether your own devices use an encrypted resolver.