Your browser can encrypt a web page while the lookup that helped it find the website travels in plain text. Encrypted DNS addresses that gap by protecting the exchange between a DNS client and its chosen resolver.
The useful question is how far that protection extends. Understanding the resolver, the application using it, and the failure behavior gives you a clearer picture than simply switching on a setting labelled secure.
Key takeaways: Protecting a DNS lookup reduces exposure along its network path. You still need to trust the resolver, check which applications use it, and understand what happens when the encrypted service cannot be reached.
What encrypted DNS changes
DNS translates names such as example.com into addresses that computers use to connect. With traditional unencrypted DNS, someone observing the lookup path can read those queries. Cloudflare’s encryption overview explains both this visibility and the possibility of interference with unprotected queries.
Consider the journey as separate exchanges: your device asks a resolver a question, receives an answer, and then connects to the destination. Encrypting the first exchange protects a specific part of that journey. It does not make every subsequent connection inherit the same privacy properties.
Two common encrypted transports
DNS over HTTPS, or DoH, carries DNS messages inside HTTPS exchanges. DNS over TLS, or DoT, uses a dedicated TLS connection. The DoT standard specifies TCP port 853 by default, while ordinary HTTPS commonly uses port 443.
| Method | Transport | Question to check |
|---|---|---|
| Traditional DNS | Commonly unencrypted | Who can observe the path? |
| DoH | HTTPS | Which app sends the lookup? |
| DoT | Dedicated TLS connection | Which resolver is authenticated? |
Both encrypted approaches can improve confidentiality in transit. The protocol name alone does not establish the logging policy, reliability, or suitability of the service at the other end. Those are separate checks.
Your resolver still needs your trust
The resolver must process your question to answer it. Moving the exchange into an encrypted connection limits what intermediaries can see, but the chosen service still handles the query. Treat provider selection as a data-handling decision as well as a connection setting.
IETF recommendations for DNS privacy operators distinguish data travelling over the network, data retained on servers, and data passed onwards. They recommend minimizing retention and describe a privacy statement that helps users evaluate an operator’s commitments.
- Identify the organization running the resolver.
- Read what it says about query logs and retention.
- Check whether it explains sharing and access to retained data.
- Separate documented practices from broad privacy slogans.
A practical decision should leave you able to explain who receives your requests and why you accept that arrangement. A familiar brand or an encrypted connection is only part of that explanation.
Privacy has boundaries beyond DNS
DoH protects the client-to-resolver exchange; it does not promise anonymity. The DoH specification discusses correlation through the underlying network and transport layers, including client addressing. Encrypting a lookup does not erase the surrounding connection metadata.
Other signals can also reveal information about a connection. Mozilla’s DoH FAQ notes the separate issue of domain exposure through unprotected Server Name Indication, a name sent during some TLS handshakes. The implication is limited but useful: DNS confidentiality cannot establish that every other layer conceals the destination.
DNSSEC addresses another boundary. It helps validate DNS data rather than encrypting the lookup. The DoH specification treats DNSSEC and encrypted transport as independent, compatible mechanisms. A secure connection to a resolver and confidence in the authenticity of an answer are related concerns with different solutions.
When evaluating a privacy claim, ask precisely what an observer loses access to. Reading the query directly, inferring a destination from other traffic, and receiving the query as the chosen resolver are different capabilities. Keeping them separate prevents a useful feature from becoming an unrealistic guarantee.
Scope and fallback change the result
Start by identifying where you enabled the feature. A browser’s DNS option describes that browser’s behavior. It is insufficient evidence that unrelated applications, another browser, or every device on the same network use an identical path. Keep the scope of your conclusion aligned with the setting you actually checked.
Failure behavior matters just as much. Google’s Chrome security guidance says automatic secure DNS mode can fall back to an unencrypted lookup when resolution has problems. Selecting a custom provider changes that behavior; Google documents that Chrome then does not default to unencrypted mode.
Firefox’s protection settings make a similar trade-off explicit. Default protection can use the normal resolver when there are problems and responds to certain network conditions. Max Protection instead presents a warning when secure resolution cannot proceed, with an option to add an exception.
Availability and strict confidentiality are different priorities during an outage. Decide which behavior you want before diagnosing a failure, rather than assuming every setting with the word secure means the same thing. A working page alone cannot confirm that the lookup used encryption.
Check the network before changing its resolver
A company or home network may rely on DNS for more than public website addresses. Mozilla’s network guidance describes internal names, different answers for internal users, and filtering performed through a network’s default resolver.
Sending those questions elsewhere can change the result. For example, an internal application name may depend on information provided by the organization’s own resolver. A public service has no obligation to know the same private names. Likewise, existing DNS filtering can be bypassed by changing where the questions go.
What to do: On a managed device or network, ask the administrator which DNS configuration is supported. Keep an approved route for internal services and filtering instead of forcing a public resolver to solve every situation.
Make one change and verify its effect
For a personal device you control, a small, reversible change is easier to assess than changing browser, operating-system and router settings together. Use the provider’s current documentation for the exact option names and supported configuration.
- Write down the starting point. Record the resolver, application and existing protection setting so you can restore them.
- Choose a documented provider. Review its privacy statement and use its published connection details.
- Choose the failure behavior deliberately. Decide whether a fallback or an explicit resolution error better matches your needs.
- Check status and normal use. Inspect the application’s secure DNS status and confirm the sites and services you need still resolve.
- Record what you verified. Note the application and network tested, rather than extending the result to the whole device.
Firefox documents an Active, Not active or Off status for the feature. That distinction is more informative than the presence of a saved preference. Recheck the result after a network change or configuration update, especially if the application has reported a problem.
Common questions
Does encrypted DNS guarantee no logs?
No. Transport encryption and the resolver’s retention practices are separate. Evaluate the service’s published data-handling commitments rather than inferring a logging policy from DoH or DoT support.
Must every device use the same provider?
There is no universal choice established by these protocols. Select a configuration that fits the device, the applications and any network requirements, then keep a record of that decision.
The practical takeaway is to protect the lookup while remaining precise about its boundaries. A documented resolver, a known scope and a verified failure policy make the feature understandable and maintainable. Those checks provide a firmer basis for privacy decisions than a reassuring toggle alone.
