What Is DNS over HTTPS (DoH)? Encrypted DNS Explained

DNS over HTTPS (DoH) is a protocol that sends DNS queries and responses inside encrypted HTTPS connections instead of as plaintext UDP packets, so anyone monitoring the network — an ISP, a public Wi-Fi operator, an attacker on the same segment — can’t see which domains a device is looking up. Ordinary DNS was designed in an era before pervasive network surveillance was a serious concern, and it shows: a standard DNS query travels unencrypted, readable by any router or observer between the client and the resolver. DoH closes that specific gap by wrapping the query in the same TLS encryption that protects HTTPS web traffic.

Why plaintext DNS is a privacy leak

Every time a browser or app resolves a hostname to an IP address, it sends a DNS query — typically over UDP port 53, in plaintext. Even if the eventual connection to that IP is encrypted, the lookup itself reveals the domain name. That’s enough for an observer to build a fairly complete picture of someone’s browsing habits — which sites they visit, when, and how often — without ever decrypting a single HTTPS session. On public networks in particular, this makes plaintext DNS one of the easier ways to passively profile a user’s activity.

DoH addresses this by making the query itself look like ordinary HTTPS traffic to anything monitoring the network. Since the query is wrapped inside a standard HTTPS request to a DoH-capable resolver, it’s indistinguishable from any other secure web request at the network level.

How a DoH lookup works

1. The client (browser, OS, or app) is configured with the URL of a DoH-capable resolver, such as a public provider’s /dns-query endpoint.
2. Instead of sending a raw UDP packet, the client formats the DNS query as the body of an HTTPS POST (or a base64url-encoded GET parameter) and sends it over a normal TLS connection to that endpoint.
3. The resolver decrypts the request, performs the DNS resolution as usual, and returns the answer as an HTTPS response — again, encrypted.
4. The client extracts the IP address from the response and proceeds with the connection.

Because the transport is HTTPS, DoH can reuse existing HTTP/2 or HTTP/3 connections, benefit from connection pooling, and pass through firewalls and proxies that already allow port 443 — which is also why some network administrators consider it a double-edged sword: the same properties that make DoH good for privacy make it harder for enterprise or parental-control DNS filtering to intercept and block specific domains.

DoH vs DNSSEC: different problems

DoH is frequently confused with DNSSEC, but the two solve different problems entirely:

	DNS over HTTPS (DoH)	DNSSEC
Problem solved	Confidentiality — hides what is being queried	Integrity — proves the answer wasn’t forged
Encrypts the query	Yes	No — DNSSEC responses are signed, not encrypted
Protects against	Network eavesdropping, on-path snooping	DNS spoofing and cache poisoning
Requires	A DoH-capable resolver and client support	A signed zone and a validating resolver

The two are complementary, not competing: DoH keeps a query private in transit, while DNSSEC lets a resolver cryptographically verify that the answer it received actually came from the authoritative source and wasn’t tampered with along the way. A fully hardened DNS setup benefits from both — encrypted transport plus verified authenticity — since one protects confidentiality and the other protects trust in the answer itself.

DoH vs DNS over TLS (DoT)

A related protocol, DNS over TLS (DoT), encrypts DNS the same way but uses a dedicated port (853) and a raw TLS connection instead of wrapping the query in HTTPS. DoT is easier for network administrators to identify and selectively block (or explicitly allow) because it runs on its own port, while DoH’s use of the standard HTTPS port makes it blend in with regular web traffic. Both achieve the same core goal — encrypting the query — and the choice mostly comes down to which one a given operating system or browser supports and how visible network administrators want DNS traffic to remain.

Where DoH runs today

DoH is commonly implemented at two layers, which don’t always agree with each other:

• Browser-level DoH — many browsers ship built-in DoH support and can route DNS lookups through a chosen provider regardless of what the operating system or VPN is configured to use, which is convenient for privacy but can bypass network-level DNS filtering that administrators rely on.
• OS-level and router-level DoH — operating systems and some router firmware support configuring DoH system-wide, so every application’s DNS traffic is encrypted, not just the browser’s.

This split matters operationally: a corporate network that filters DNS at the router to block malicious domains can be silently bypassed if a browser has its own DoH resolver configured, since the browser’s queries never touch the local resolver the network is monitoring. This is one reason some enterprise environments explicitly disable browser-level DoH and enforce DNS resolution — encrypted or not — through a single, monitored path.

The takeaway

DNS over HTTPS wraps DNS queries in HTTPS to hide them from network-level eavesdroppers, closing a long-standing privacy gap in plaintext DNS. It solves confidentiality, not authenticity — pair it with DNSSEC if you also need cryptographic proof that DNS answers haven’t been forged. The main practical wrinkle is that browser-level DoH can route around network or router-level DNS filtering, which is exactly why some organizations manage it deliberately rather than leaving it to each application’s default.