Opening a website usually starts before the browser sends an HTTP request. The device first needs an IP address for the hostname, and DNS commonly provides that mapping. Traditional DNS traffic can expose those queries to systems along the network path because classic resolver exchanges are not encrypted by default.

DNS over HTTPS, usually shortened to DoH, changes the transport. It sends DNS messages through HTTPS, so the request and response receive the confidentiality and integrity protection of the HTTPS connection between the client and the selected resolver.

That sounds like a small transport detail, but it changes which systems can inspect or modify resolver traffic and which system becomes responsible for answering the queries.

The DNS message still asks the same kind of question

DoH does not replace the DNS naming system. A client can still request records such as A, AAAA, MX, or TXT records, and a recursive resolver can still contact authoritative DNS infrastructure as needed to obtain an answer.

The major change is how the client reaches its recursive resolver. Classic DNS commonly uses UDP or TCP on port 53. DoH packages DNS messages into HTTP exchanges carried over TLS, normally using the same port 443 associated with HTTPS web traffic.

The application therefore gains an encrypted channel to the resolver. A local observer can see that the client is communicating with a particular server, but it cannot simply read the DNS message from the encrypted payload.

This distinction matters because encryption protects the resolver exchange in transit. It does not alter the record stored in DNS or turn DNS itself into a different naming database.

Local networks lose direct visibility into encrypted queries

On a traditional network, a router, hotspot operator, internet provider, or other device positioned along the path may be able to observe plaintext DNS requests. Those requests can reveal hostnames even when the later web connection uses HTTPS.

With DoH, the hostname being requested from the resolver sits inside the encrypted HTTPS session. A passive system between the client and resolver cannot read that request merely by inspecting packets.

The same protection also makes simple in-path modification harder. A network device cannot rewrite an encrypted DNS response without breaking the authenticated TLS connection.

This can be useful on untrusted networks, but it can also bypass local DNS features. A home router or company network may provide local hostnames, filtering, logging, split DNS, or policy enforcement through its configured resolver. An application that independently sends DoH requests to an external resolver may not receive those local answers.

Modern operating systems and browsers use different policies to reduce such conflicts. Some integrate encrypted DNS with system resolver settings, while others can select or configure a resolver at the application level. The exact behavior depends on the platform and configuration.

The resolver still sees the queries

Encrypting the path does not make DNS queries invisible to the resolver receiving them. The DoH service terminates the HTTPS connection, processes the DNS message, and can therefore see the requested name.

Privacy is consequently shifted rather than made absolute. A local network may lose direct access to plaintext DNS traffic, while the chosen resolver remains in a position to process query data.

Resolver choice still matters. Operational policies can differ in areas such as retention, logging, filtering, geographic routing, and support for security features. DoH provides transport encryption; it does not impose one universal data-handling policy on every resolver.

The recursive resolver may also communicate with other DNS servers while resolving a name. DoH specifically describes the HTTPS transport used for DNS messages on a supported connection. It does not imply that every subsequent DNS exchange across the global resolution chain uses the same encrypted transport.

A common mistake is to treat encrypted DNS as complete destination privacy. Network traffic contains more information than DNS packets alone.

After resolution, the client normally connects to an IP address. Systems along the path can still observe destination IP addresses and traffic patterns. A single IP address may host many services, so an address does not always identify one hostname, but it remains useful metadata.

TLS can expose additional information depending on the protocol version and features in use. Technologies that encrypt more of the TLS handshake can reduce visible hostname metadata, but their deployment and behavior are separate from DoH.

Applications can also contact services without performing a fresh DNS lookup because an answer remains cached. Conversely, one page can trigger requests to several hostnames for scripts, images, analytics, APIs, or content delivery. DNS visibility and web activity therefore do not map neatly one query to one page view.

DoH should be viewed as protection for the resolver channel, not as a general-purpose anonymity system.

HTTPS gives DNS familiar transport properties

Using HTTPS gives DoH several properties already common in web infrastructure. TLS authenticates the server according to the certificate and hostname checks performed by the client, while encryption protects message contents against passive inspection on the path.

HTTP also allows DNS exchanges to use established connection behavior such as persistent sessions and multiplexing when supported by the HTTP version. Multiple resolver requests can travel through an existing secure connection rather than requiring a new TLS handshake for every query.

The trade-off is that DNS traffic now shares a general HTTPS transport instead of having the obvious network signature of port 53. Network administrators cannot rely on the same simple port-based controls to identify every resolver request.

Managed environments may therefore configure approved encrypted resolvers, use endpoint policy, or integrate DNS controls at the operating-system level instead of assuming that all DNS leaves through one visible local service.

DoH and DNS over TLS protect a similar boundary

DNS over TLS, commonly called DoT, is another encrypted transport for DNS. It places DNS traffic directly inside TLS and commonly uses port 853. DoH instead carries DNS through HTTP over TLS and normally uses port 443.

Both can protect the client-to-resolver exchange from passive plaintext inspection. Their operational characteristics differ because one uses a dedicated DNS-oriented port while the other fits into HTTPS infrastructure.

That difference can affect deployment, network policy, application integration, and traffic management. It does not make one transport automatically private in every scenario. Resolver policy, endpoint security, surrounding metadata, and configuration remain relevant with either approach.

Encrypted DNS changes the trust boundary

The practical effect of DoH is easiest to describe as a shift in the resolver path. The client creates an authenticated encrypted connection to a resolver and places DNS messages inside it. Intermediate networks no longer receive those messages as readable DNS packets.

The resolver, however, still handles the queries, and the later internet connection still exposes metadata needed for routing. Local DNS features can also behave differently when software chooses a resolver outside the network’s normal configuration.

DoH is therefore a focused transport protection. It reduces plaintext DNS exposure between a client and resolver while leaving the broader questions of resolver trust, destination metadata, network policy, and application privacy to other parts of the stack.

DNS HTTPS Privacy Networking