DNS over HTTPS vs DNSSEC: What Each One Actually Protects
DoH and DoT encrypt the hop between you and your resolver. DNSSEC proves the data is genuine. What each protects, what neither hides, and how to test both.
Published: · 7 min read
DNS over HTTPS (DoH) and DNSSEC are not alternatives. They solve two different problems and work best together. DoH (and its sibling DoT) encrypts the conversation between your device and your DNS resolver, so nobody on the network in between can read or change your queries. DNSSEC signs the DNS data itself, so a resolver can verify that an answer is exactly what the zone owner published. The first gives privacy and integrity on one hop; the second gives authenticity end to end, with no privacy at all. If you own a domain, only one of them is yours to switch on.
The path of a DNS query
Two hops matter:
your device (stub resolver)
│ hop 1: DoH / DoT / DoQ protect this
▼
recursive resolver (ISP, company, public resolver)
│ hop 2: plain DNS to root, TLD and the domain's nameservers
▼
authoritative servers ← DNSSEC signs the data that originates here
The recursive resolver does the work of walking from the root to the domain's authoritative servers and caches the result. Classic DNS sends everything on both hops in clear text, mostly over UDP port 53.
What DoH, DoT and DoQ do
Three standards wrap DNS messages in an encrypted, authenticated transport:
| Protocol | Standard | Transport |
|---|---|---|
| DNS over TLS (DoT) | RFC 7858 | TLS on TCP port 853 |
| DNS over HTTPS (DoH) | RFC 8484 | HTTPS on port 443, media type application/dns-message |
| DNS over QUIC (DoQ) | RFC 9250 | QUIC on UDP port 853 |
All three protect hop 1. With DoH, and with DoT in its strict mode, the client verifies the resolver's TLS certificate, so it knows it is talking to the resolver it chose, and on-path observers (the Wi-Fi operator, the ISP, anyone who has tampered with the local network) can neither read the queries nor alter the answers. The practical difference is visibility: DoT uses its own port and is easy to identify or block, while DoH is ordinary HTTPS traffic on port 443 and blends in with web browsing.
What they do not do:
- They do not prove the data is genuine. The resolver could be misconfigured, compromised, or deliberately rewriting answers, and an encrypted channel delivers a wrong answer just as faithfully as a right one. You are trusting the resolver.
- They do not hide anything from the resolver. Its operator still sees every name you look up. Encrypted DNS moves trust from the local network to the resolver operator; it does not remove it.
- They say nothing about hop 2, which in general remains unencrypted.
What DNSSEC does
With DNSSEC (RFC 4033, 4034 and 4035) the zone owner signs every record set. A validating resolver checks those signatures against the zone's DNSKEY, checks that key against the DS record in the parent zone, and so on up to the root key it has built in. The result is origin authentication and integrity: the answer came from whoever holds the zone's keys and was not modified anywhere on the way, including on hop 2 and inside caches. A forged answer fails validation and the resolver returns SERVFAIL instead of passing it on.
DNSSEC provides no confidentiality whatsoever. Queries and signed answers travel in clear text; signatures make them bigger, not secret. The mechanics are covered in what DNSSEC is and how to enable it.
Side by side
| DoH / DoT / DoQ | DNSSEC | |
|---|---|---|
| Protects | the channel between client and resolver | the DNS data itself |
| Property | confidentiality and integrity on that hop | authenticity and integrity from the zone to the validator |
| Against whom | observers and tamperers on the local network and the ISP path | anyone forging answers: off-path spoofers, poisoned caches, tampering between resolver and authoritative servers |
| Does not help against | a lying or logging resolver | eavesdropping; a compromised DNS account at the zone owner |
| Who enables it | the user, OS, browser or network admin, plus the resolver operator | the domain owner (signing, DS at the registrar), plus resolvers that validate |
| Visible to the network | that you talk to a resolver, not what you ask | every query and answer |
| Needs action by the zone owner | no | yes |
What neither of them hides
Encrypted DNS is sometimes described as hiding which sites you visit. It hides the lookup, which is less than that:
- The IP address you connect to afterwards is visible to the same network, and for many sites the address alone identifies the site.
- The hostname in the TLS handshake. The Server Name Indication (SNI) field is normally sent unencrypted, so the name you just looked up privately appears in clear text a moment later.
- The resolver operator's view, as noted above. Oblivious DoH (RFC 9230, experimental) splits that knowledge between a proxy and the resolver, but it is not what ordinary DoH clients use.
Where the two meet: the AD flag
A validating resolver sets the AD ("authenticated data") flag in responses it has validated. But a flag in a clear-text UDP packet is only as trustworthy as the network it crossed: whoever can forge the answer can set the bit too. The AD flag means something to a client only when hop 1 is a secure channel to a resolver it trusts. That is exactly what DoT and DoH provide. DNSSEC secures the data up to the resolver; encrypted transport carries the resolver's verdict safely over the last hop. The alternative is to validate on the device itself, which few stub resolvers do.
If you own a domain
- DoH/DoT: nothing to configure. It is a choice made by clients and resolvers. There is no record to add, and your domain does not "support" or "lack" DoH. Visitors using encrypted DNS receive the same records as everyone else.
- DNSSEC: this one is yours. Sign the zone at your DNS host and publish the DS record through your registrar. Afterwards, handle nameserver moves with care, because a stale DS record takes the domain offline for every validating resolver.
If you run a network
Browsers can use DoH with a resolver of their own choosing, bypassing the resolver your DHCP hands out. That affects resolver-based content filtering, security blocklists, and split-horizon DNS (internal names that only your resolver knows). Your options:
- Firefox checks the canary domain
use-application-dns.net; if your resolver answers it with NXDOMAIN, Firefox does not enable DoH by default. It does not override a user who turned DoH on explicitly. - Browsers and operating systems offer enterprise policies to disable DoH or pin it to a resolver you specify.
- Better: offer DoT or DoH on your own resolver, so clients get encryption without leaving your policy.
Testing from the command line
DNSSEC, through a validating resolver:
$ dig +dnssec example.com
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
example.com. 3600 IN A 192.0.2.10
example.com. 3600 IN RRSIG A 13 2 3600 … example.com. …
Look for the RRSIG (the zone is signed) and for ad among the flags (this resolver validated it). No ad on a signed domain usually means the resolver does not validate. delv example.com, shipped with BIND, performs the validation locally and prints ; fully validated.
Encrypted transport, with dig from BIND 9.18 or later, or with kdig from Knot DNS:
$ dig +https @resolver.example example.com
$ dig +tls @resolver.example example.com
$ kdig +tls @resolver.example example.com
Replace resolver.example with the hostname or address of a resolver that offers the protocol; several public resolver operators do, and they document their endpoints. The answer looks like any other; only the transport differs.
Common mistakes
- Treating DoH as a replacement for DNSSEC, or the reverse. An encrypted channel to a resolver that does not validate still delivers forged data.
- Looking for a "DoH record" to add to a domain. There is none.
- Believing DNSSEC encrypts DNS. It does not hide a single byte.
- Assuming encrypted DNS makes browsing private. The destination IP address and the SNI remain visible.
- Trusting the
ADflag received over plain UDP from a resolver across an untrusted network. - Turning DoH on in a company browser and then wondering why internal hostnames stopped resolving.
- Blocking port 853 and believing encrypted DNS is dealt with. DoH runs on 443.
Check it with OrbitProbe
The OrbitProbe DNS lookup shows the records that public resolvers return for a domain at that moment, with their TTLs. That is the view visitors get whichever transport their device uses, because DoH and DoT change how the answer travels, not what it contains. For the signing side of the same domain, there is the DNSSEC checker. For background on the records involved, see DNS record types explained and, for how long resolvers keep an answer, what TTL means in DNS.