DNS over HTTPS vs VPN: Why Encrypted DNS Is Not a VPN Replacement

Direct answer: DNS over HTTPS (DoH) encrypts the DNS request that turns a name such as www.example.com into an IP address. A VPN encrypts and routes much more of a device’s network traffic through a VPN server. For people deciding whether DoH can replace a consumer VPN app—especially on public Wi-Fi, a home connection, or a network operated by an employer or school—the answer is no: DoH addresses one important metadata channel, while a VPN changes the network path seen by the local network and destination sites.

What DoH protects—and the narrow job it performs

Before an application connects to most internet services by name, it needs DNS. Traditionally, a device might ask a local resolver, “What address should I use for this hostname?” DoH sends that DNS question and its response using HTTPS. As RFC 8484 explains, this uses HTTPS mechanisms and TLS confidentiality and integrity for DNS exchanges. In practical terms, an on-path observer between the device and the selected DoH resolver should not be able to simply read or alter that DoH exchange in the way it could with unencrypted DNS.

That can be valuable on an untrusted local network. It can also reduce the ability of a local access provider or Wi-Fi operator to inspect ordinary DNS messages sent to the chosen resolver. But encrypted transport does not erase the fact that a resolver receives a request. The resolver is still a party that must answer it.

DoH also does not encrypt every connection made after name resolution. A browser may use TLS to protect the contents of a visit to an HTTPS website; an email app may use TLS for its mail connection; another application may use a different protocol altogether. DoH is specifically about the DNS layer. It does not place all of those separate connections inside one encrypted tunnel.

Resolver trust: RFC 8484’s privacy boundary

The clearest way to assess DoH is to ask: which observer loses visibility, and which observer gains or retains it? RFC 8484’s privacy considerations separate transport privacy from resolver privacy in Sections 8.1 and 8.2. Its transport discussion recognizes the benefit of HTTPS protection between the client and the DoH server. Its resolver discussion makes the equally important point that a DoH resolver can see the DNS information entrusted to it.

That means DoH changes the trust relationship; it does not eliminate it. A network that previously handled visible DNS may see less of the query itself, while the designated resolver receives it over an authenticated encrypted connection. The resolver’s policies, retention practices, jurisdiction, operational security, and any applicable account relationship therefore remain relevant considerations. Encryption in transit is not evidence that the resolver collects no data, retains no data, or cannot associate requests under any circumstances.

RFC 8484 Section 8.2 also highlights a key correlation issue: depending on deployment, DNS information can be associated with client addressing information. A direct DoH client normally connects to the resolver from its network-facing IP address. Even where an intermediary is involved, the privacy result depends on the actual architecture and on what identifying information is passed along. Neither the standard nor the existence of HTTPS establishes a universal anonymity outcome.

This is why “encrypted DNS” and “private browsing” should not be treated as synonyms. DoH can make DNS handling more confidential on the path to the resolver, but it cannot by itself prevent every form of identification, logging, account-based linkage, or traffic analysis.

DNS lookup, application TLS, and routing are three different layers

Confusion in the dns over https vs vpn comparison often comes from grouping three separate functions under the word “privacy.” They should be evaluated independently.

• DNS lookup: DoH protects the request to a DNS resolver. It helps conceal the requested name from many observers on that DNS transport path, but the resolver receives the query.
• Application TLS: HTTPS and other TLS-protected application connections protect data exchanged with the intended service. RFC 8446 describes TLS 1.3 as a secure channel designed to prevent eavesdropping, tampering, and message forgery. This protects the connection’s content when correctly deployed; it does not inherently conceal every network-level fact about the connection.
• Routing: Without a VPN, the device ordinarily connects from its public network address toward the service’s address. A local network or access provider can often observe that the device is communicating with particular IP addresses, along with timing, volume, and other traffic characteristics. With a full-tunnel consumer VPN, the local network instead generally sees an encrypted connection between the device and VPN server, while the destination service generally sees the VPN server’s egress address rather than the device’s home or café-facing address.

A VPN therefore addresses a different observation point. It does not replace application TLS: the website should still use HTTPS. It does not make a device safe if malware, a malicious browser extension, or an attacker with control of the device can observe activity before encryption or after decryption. And it does not promise anonymity, because accounts, browser fingerprinting, cookies, payment records, service logs, and traffic correlation may still connect activity to a person or device.

For a fuller foundation, see VPN Service Explained - What is VPN Service & How does it work and Understanding the Technology Behind VPN.

A worked everyday scenario: café Wi-Fi and an HTTPS store

Imagine Sam joins café Wi-Fi and opens an HTTPS shopping site. With DoH enabled, Sam’s device sends the DNS lookup for the store through an HTTPS connection to its chosen DoH resolver. The café network may be unable to read the DNS name inside that protected DoH request. The resolver can receive the lookup and may see the source IP presented by Sam’s connection, subject to the deployment.

Next, Sam’s browser connects to the store. HTTPS protects the pages, credentials, and purchase data in transit between browser and store when the connection is valid. But DoH does not route this web connection through the DNS resolver. The café network can still observe a connection leaving Sam’s device toward the store’s network address or related infrastructure, as well as timing and data volume. The store generally receives Sam’s café-facing public IP address unless another routing service is used.

If Sam uses a properly configured consumer VPN app that routes the relevant traffic through its tunnel, the café instead generally observes the device’s encrypted VPN connection. The store generally sees the VPN exit address. The VPN operator, however, becomes a significant network intermediary: it can observe at least some connection metadata needed to operate the service, and the precise visibility depends on its architecture and protocol. DoH may still be used inside the tunnel, but it is not what creates the changed routing path.

The evidence does not establish that either choice makes Sam unidentifiable, hides all destinations from every party, defeats account tracking, or prevents a compromised device from leaking data. It establishes narrower transport and routing properties.

Enterprise gateways and consumer VPN apps are not interchangeable

An enterprise VPN gateway commonly exists to give managed devices or authorized users access to internal systems and to apply organizational controls. The organization may route traffic through security systems, enforce DNS choices, require device management, and retain logs under its policies. In that setting, a VPN is often an access and governance tool as well as a tunnel. Employees and students should follow the organization’s acceptable-use and security rules rather than assume that encryption makes activity invisible to the organization.

A consumer VPN app usually has a different purpose: it routes a subscriber’s traffic to a provider-operated exit network, potentially reducing what the local access network sees and changing the public IP seen by a destination. It is not an enterprise gateway merely because both are called VPNs. When comparing consumer services, examine the provider’s stated privacy policy, supported platforms, jurisdictional context, security features, and limitations—not just the presence of a “no logs” marketing phrase. Our guide on How to Choose The Right VPN outlines questions worth asking, and the About Us page explains this site’s purpose.

Concrete choices for readers

1. Use HTTPS sites and heed certificate warnings. DoH is not a substitute for application-layer encryption. Do not continue through browser security warnings unless you understand and accept the risk.
2. Decide who should receive DNS queries. If using DoH, review the resolver’s documented policy and configuration rather than assuming HTTPS answers every privacy question.
3. Use a VPN when the routing goal fits. A reputable consumer VPN can reduce exposure of destination connections to a local network and replace the public IP visible to sites with an exit IP. It cannot guarantee anonymity or secure an already compromised device.
4. Understand split tunneling and managed-network rules. A VPN only protects traffic that actually traverses it. On work or school devices, organizational configuration can determine DNS and routing behavior.
5. Reduce account and fraud risk separately. Unique passwords, multifactor authentication, prompt updates, and careful handling of links address risks that neither DoH nor a VPN solves. See Protect Yourself from Identity Theft & Online Fraud.

Takeaway

DoH is encrypted DNS transport: it can protect DNS lookups from many on-path observers, while asking users to trust a resolver. A VPN is a routing tunnel: it can change what the local network and destination service see about a connection, while asking users to trust the VPN operator. Using both can be sensible in some configurations, but neither replaces HTTPS, secure devices, or sound account security. Choose the tool based on the observer and data flow you are trying to address—not on a claim that one privacy feature solves every layer.