Secure DNS Hides the Lookup, Not the Whole Website Visit

Secure DNS encrypts the request your device makes to translate a domain name into an IP address. It can prevent a basic local-network observer from reading or changing that lookup in transit. It does not hide every destination from your network, encrypt an insecure webpage or make you anonymous.

Why DNS needs a protected channel

Before a browser can open a site, it usually asks a DNS resolver where that site's server lives. Traditional DNS sends many of those questions without transport encryption. DNS over HTTPS, commonly shortened to DoH, places the lookup inside HTTPS. DNS over TLS uses a dedicated encrypted channel. Both aim to protect the query between your device and the resolver.

Chrome calls its control Use secure DNS. Google says automatic mode can fall back to an unencrypted lookup if the protected lookup fails. Selecting a custom provider changes that behavior: Chrome says it will not fall back to an unencrypted mode for that provider, so a resolver outage may instead produce an error. Firefox similarly lets users choose increased protection and a provider, subject to network and policy conditions.

What it does not conceal

After DNS gives the browser an address, the browser still has to connect to the destination. HTTPS protects page contents in transit, but other connection details can still reveal information to the network or service providers. The resolver itself receives the DNS question unless a more complex proxy design is used. The website sees the connecting address unless another network layer changes it.

• Secure DNS is not a VPN. It does not reroute all device traffic through a different exit.
• It does not repair a phishing site or certify that a domain is trustworthy.
• It does not replace HTTPS. An HTTP page can still expose content in transit.
• It does not stop tracking performed by the site, account or browser storage.

Automatic or custom provider?

Automatic mode is the low-friction choice. It often upgrades lookups while preserving compatibility with a network's resolver. A custom provider gives you a clearer resolver choice and may prevent silent downgrade, but it moves trust to that provider and can interfere with parental controls, company filtering or hotel sign-in systems. Read the provider's retention and filtering policy, not only its speed claims.

When a network breaks

A managed device may lock the feature. Captive portals and filtered networks may expect their own DNS behavior. If a site fails only after choosing a custom resolver, temporarily return to automatic mode, confirm the device clock, and test another known site. Do not disable every security control because one hotel login page is confused.

A sensible configuration

1. Keep the browser and operating system updated.
2. Turn on secure DNS in the browser's privacy or security settings.
3. Use automatic mode unless you have a reason to select and trust a provider.
4. Also enable the browser's HTTPS-only or always-secure-connections mode.
5. Remember that account privacy, cookies and site permissions remain separate problems.

Secure DNS solves a narrow, real problem: exposed name lookups. It is worth enabling when it works on your network, especially alongside HTTPS. The correct mental model is an encrypted address-book request—not an invisibility cloak for everything that follows.