DNS over HTTPS and DNS over TLS protect the connection between a device and its recursive resolver from eavesdropping and tampering. DNSSEC protects the data itself by signing it. They are separate, compatible tools. Using one does not give you the others.
What each one protects
- DoT (RFC 7858): protects query content on the link to the resolver. It does not prove the data's origin.
- DoH (RFC 8484): protects the same link, carried inside HTTPS. Same limits as DoT.
- DNSSEC (RFC 4033): protects authenticity and integrity of answers. It gives no confidentiality.
DNS over TLS
RFC 7858 wraps DNS traffic between a client and its recursive resolver in TLS. Servers listen on TCP port 853 by default, and that port must not carry cleartext DNS. The RFC notes it does not fully hide traffic patterns: timing and message sizes can still leak, and padding is a partial mitigation.
It defines two profiles. Opportunistic privacy uses encryption when available but does not authenticate the server, so an active attacker can strip the protection. The out of band key pinned profile connects only to servers whose public key fingerprint matches a pre-configured pin, which helps against person in the middle and downgrade attacks.
DNS over HTTPS
RFC 8484 carries each DNS query and response in one HTTP exchange, using HTTPS so TLS supplies integrity and confidentiality. Its stated aims are to stop on-path devices from interfering with DNS and to let web applications reach DNS through browser APIs consistently with CORS. It uses the default HTTPS port 443 and a dedicated media type for DNS messages.
Because DoH rides on port 443, it is harder for a network to distinguish from other web traffic. That is a privacy gain for users and a visibility problem for network defenders.
DNSSEC
DNSSEC signs record sets so a validating resolver can detect forged answers. See DNSSEC explained. It gives integrity, not privacy.
Which to use
- Home and roaming users worried about snooping on coffee shop networks: an encrypted DNS option in the operating system or browser.
- A company with DNS based filtering or monitoring: DoT to a resolver you control, and a policy on browser DoH so devices do not bypass your controls.
- A domain owner worried about forged answers: DNSSEC on your zone, if you can operate it.
- All of them: the three combine, since encrypted transport and signed data cover different gaps.
Limits to remember
The resolver still sees every name you look up. Encrypting the link moves trust to the resolver operator, so pick one deliberately. Also, the IP address you then connect to remains visible. RFC 9849 notes plaintext DNS queries and visible server addresses can still reveal a destination even when the TLS handshake hides the server name. See Encrypted Client Hello explained.
Quick check
Does DoH replace DNSSEC?
No. DoH secures the path to the resolver. It does not prove the answer came from the zone owner.
Is DoT or DoH better for an enterprise?
It depends on what you need to control. DoT uses its own port, which makes it easier to manage and block at the network level. DoH blends with web traffic.
Sources
- RFC 7858, DNS over TLS
- RFC 8484, DNS Queries over HTTPS
- RFC 4033, DNSSEC
- RFC 9849, Encrypted Client Hello
Last reviewed: 19 October 2026.
