Encrypted DNS: Choose Who Handles Your Website Lookups

DNS turns a name such as example.com into an address that software can use. With ordinary DNS, a network carrying the traffic may often observe or alter those lookups. DNS over HTTPS (DoH) sends DNS requests and responses through HTTPS, using TLS for confidentiality and integrity on that connection, as specified in RFC 8484. That is valuable against on-path observation and interference. But the resolver necessarily receives the queries it answers. The central privacy question therefore becomes: which organisation is receiving this record of requested domain names, under what rules, and with what other information can it associate it?

Encryption changes the observer, not the meaning of a DNS query

DNS data can be revealing even though it is not a complete browsing history. A lookup may indicate interest in a bank, health portal, employer service, school platform, messaging provider, streaming site, or advertising domain. It may also reveal the applications and background services a device uses. Conversely, a DNS lookup alone does not reliably prove that a person loaded a particular page, read a particular article, logged in, or completed a transaction. Caches, prefetching, blocked connections, shared devices, and application behaviour all complicate that inference.

DoH is often described as “encrypted DNS,” which is useful shorthand but incomplete. The protocol uses HTTPS URIs and HTTP mechanisms rather than merely wrapping old DNS packets in an arbitrary encrypted pipe. RFC 8484 describes a design intended to prevent on-path devices from interfering with DNS operations, while retaining HTTP features such as caching and proxying. That means a Wi-Fi hotspot, local network administrator, or ISP may have less direct visibility into the DNS exchange between the client and the selected resolver. It does not mean the destination website, the resolver, or every other participant loses visibility.

HTTPS itself is an important part of the protection. TLS 1.3 is designed to provide a secure channel against eavesdropping, tampering, and message forgery, and encrypts most handshake messages; its public-key key exchanges provide forward secrecy by design, according to RFC 8446. Those properties protect traffic in transit when implementation and certificate validation work as intended. They do not dictate what a resolver logs after it decrypts and processes a query, nor do they prevent an account-based service from connecting activity to an account.

A useful mental model is that encrypted DNS protects a route, not a promise of anonymity. It can reduce one observer’s access while concentrating visibility with another. Whether that trade is attractive depends on the parties involved, the network, and the resolver’s governance.

Resolver trust means asking policy, operational, and correlation questions

A resolver is not just a technical endpoint. It is operated by an ISP, public DNS company, employer, university, VPN provider, device platform, security vendor, or another organisation. Each may have different incentives, legal obligations, abuse-prevention needs, business models, and retention practices. A thoughtful selection starts with questions that are more specific than “does it support encryption?”

• Who operates the resolver? Identify the legal entity and the service actually handling the request, including whether it relies on another resolver upstream.
• What does the published privacy policy say about DNS data? Look for query logs, source IP addresses, timestamps, diagnostic data, account identifiers, and whether information is used for security, analytics, advertising, or product improvement.
• What retention periods are stated? “No logging” can be ambiguous without definitions. A policy may distinguish transient operational records from longer-lived logs, aggregated statistics, or security incident data.
• Can requests be associated with other data? A resolver may receive a source address, a device or account signal, or requests carried in a browser session. RFC 8484’s privacy discussion is a reminder that correlation risks matter: encrypting a DNS transaction does not automatically prevent the resolver or associated service from linking information available to it.
• Is filtering involved? Malware, parental-control, and content-filtering resolvers may need to apply categorisation or policy to queried names. That can be useful, but it is a different service and should be evaluated on its stated data handling and error-correction process.
• How are changes communicated? A readable policy, version history, contact route, and explanation of applicable jurisdiction make it easier to assess a service over time.

Published policies are evidence of commitments, not proof that every internal system behaves perfectly or that future practices cannot change. Technical architecture may reduce what is retained, but a reader should not infer more than the operator documents. If the stakes are high, consider whether a service offers documentation appropriate to that risk, and seek specialised advice where necessary.

A worked everyday scenario: home Wi-Fi, a browser, and a work laptop

Consider Maya, who uses café Wi-Fi for personal browsing and occasionally opens a work laptop. On her phone, she enables a browser’s encrypted DNS setting and selects a public resolver. The café operator may no longer see those browser DNS lookups in the same way it could with unencrypted DNS. Yet the selected public resolver can receive the lookup requests needed to answer them. The websites Maya visits still receive connections from her device and may collect information through their own services. Encrypted DNS does not replace HTTPS to websites, account security, or safe device practices.

On the work laptop, the situation may be different. An employer may route DNS through an enterprise security gateway to detect malicious domains, enforce policy, investigate incidents, or meet organisational requirements. A browser independently switching to an outside DoH resolver can undermine that arrangement or simply fail because managed settings take precedence. The relevant trust decision is not automatically “public resolver good, enterprise resolver bad.” It is whether the device is managed, what notice and policy apply, what security function is needed, and who is authorised to change the configuration.

Now add a consumer VPN app. A VPN creates an encrypted tunnel between the device and the VPN service, while DNS may be resolved by the VPN provider, by a resolver it designates, or—if configuration is faulty—outside the tunnel. Thus a VPN subscription does not answer the resolver-trust question by itself. Readers comparing such services can separate general VPN concepts from provider claims in VPN Service Explained - What is VPN Service & How does it work and use a policy-focused comparison approach in How to Choose The Right VPN. Provider review pages, such as the ExpressVPN Review or Private Internet Access Review, should be read as starting points for checking current documentation rather than as substitutes for it.

Consumer controls and enterprise gateways solve different problems

Consumer browser and operating-system controls generally give an individual a choice of resolver and may protect DNS from the immediate access network. They can also create inconsistency: one browser may use DoH while another application uses the operating system’s resolver. A router-level setting can centralise household DNS, but visiting devices, browser settings, mobile-network behaviour, and VPN apps can still produce exceptions. The practical task is to understand which layer is making the DNS decision.

Enterprise gateways are commonly deployed for a different set of goals: security monitoring, protective blocking, internal-name resolution, auditing, and consistent policy across managed endpoints. Their visibility can be broader, and employees or students may not have the same freedom to choose an external resolver. Organisations should communicate this plainly and make technical choices proportionate to their purpose. Individuals should follow applicable device and network rules rather than treating encrypted DNS as a way to bypass safeguards or controls.

Consumer VPN apps likewise need careful distinction from DoH. A VPN can change the network path for more than DNS traffic, depending on its configuration, whereas DoH specifically protects DNS exchanges with a resolver. Neither technology promises invisibility to all parties. For a broader explanation of layers and limits, see Understanding the Technology Behind VPN.

Concrete actions before selecting or changing a resolver

1. Map the device and network. Determine whether DNS is set in the browser, operating system, router, VPN app, or a managed profile. Do not assume one setting controls every application.
2. Identify the operator behind the endpoint. Record the provider name and read its current DNS-specific privacy terms, not only marketing language.
3. Compare retention and linkage statements. Note what the provider says about source addresses, timestamps, account data, diagnostics, aggregation, and deletion. If the wording is unclear, treat the uncertainty as part of the decision.
4. Check the security trade-off. Decide whether filtering, parental controls, split-horizon internal DNS, or workplace protection are required. A resolver selected solely for privacy may not meet every operational need.
5. Use HTTPS and sound account security as separate controls. Verify site security indicators where appropriate, use strong unique passwords and multi-factor authentication when available, and keep devices updated. Guidance on broader fraud risks is available in Protect Yourself from Identity Theft & Online Fraud.
6. Revisit the choice after changes. Policies, ownership, apps, and managed-device rules can change. Keep a record of why the resolver was selected and where to find its current policy. For questions about this site’s editorial approach, visit About Us or Contact Us.

What the evidence does not establish

The existence of DoH and TLS does not establish that a particular resolver never logs data, never receives a legal demand, never experiences a breach, or cannot correlate requests with other information it possesses. It also does not establish that a resolver is faster, safer, or more private than every alternative; those conclusions require provider-specific, time-sensitive evidence. Nor can DNS encryption prevent tracking conducted through website logins, cookies, browser fingerprinting, app identifiers, or direct connections. It cannot repair a compromised device, and it does not replace HTTPS between a browser or app and the service being used.

Takeaway: encrypted DNS is a useful transport protection, but its privacy value depends on a deliberate trust choice. Choose a resolver by examining who operates it, what it says about retention and correlation, how it fits the device and network, and which other parties remain able to observe activity.