DNS over HTTPS (DoH) encrypts DNS queries and responses between a compatible browser or device and its DNS resolver. It helps protect website lookups from people monitoring or interfering with that connection. It does not make you anonymous, hide all internet activity, or replace a VPN.
When I assess a privacy setting, I want to know what it protects, who I still need to trust, and whether it will disrupt everyday work. That is the useful way to approach DoH, especially if you run a business, manage a website, or regularly work outside your office.
This guide explains what DNS over HTTPS means, how it works, how to enable it, and how to check its limitations before relying on it.
What is DNS over HTTPS
DNS stands for Domain Name System. It helps devices find the network addresses associated with domain names. You remember a name such as safikul.com; your browser needs address information to establish a connection.
Traditional DNS commonly sends queries without encryption over UDP or TCP port 53. Someone able to observe that traffic may be able to read the queried domain names, even when the website itself uses HTTPS.
DoH carries these DNS messages inside an encrypted HTTPS connection. The IETF specification RFC 8484 defines how DNS requests and responses map to HTTP exchanges.
If you are asking “what is DoH (DNS over HTTPS)?”, DoH is simply the abbreviation for this encrypted DNS transport. “Secure DNS” is a related settings label you may see in browsers, although the exact behavior depends on the software.
How DNS over HTTPS works
Imagine opening a supplier’s website from a café. If the required answer is not already cached, a typical lookup follows this sequence:
1. Your browser or device prepares a DNS query for the supplier’s domain.
2. A DoH client sends that query through HTTPS to the configured resolver.
3. The resolver checks its cache or obtains an answer from the DNS system.
4. It returns the DNS response through the encrypted connection.
5. Your browser uses the result to connect to the website.
The encrypted part described here is the connection between the DoH client and resolver. DoH does not automatically encrypt every subsequent lookup the resolver makes to authoritative DNS servers.
Also, DNS generally concerns names and records, not a complete page URL. Looking up example.com is different from sending the URL example.com/customer/invoice to a DNS resolver. MDN’s DoH overview provides a concise technical introduction.
Why DNS privacy matters
Domain lookups can reveal interests, services used, and patterns of activity. That makes them worth protecting even though they do not contain everything you read or submit on a website.
For a business owner, the practical benefit is reducing unnecessary exposure while employees research suppliers, access online tools, or work from shared networks. The value comes from protecting a specific part of the connection.
DoH also makes it harder for an attacker on that connection to read or modify the protected DNS exchange. This does not guarantee that every answer is correct: resolver security and the authenticity of DNS data still matter.
My recommendation is to treat encrypted DNS as one component of sensible security. Keep browser updates, account protection, website HTTPS, and device security in the same conversation.
What DoH protects and what remains visible
| Question | What DoH changes | What it does not guarantee |
|---|---|---|
| Can someone on Wi-Fi read my DNS queries? | Encrypts queries sent over the DoH connection | Other traffic can still reveal information |
| Can the resolver see my queries? | Protects transport to the resolver | The resolver still processes those queries |
| Does it hide my public IP address? | No IP masking by itself | Websites can still see your connecting IP |
| Does it encrypt website content? | Protects DNS messages | Website HTTPS protects the web connection |
| Does it stop phishing? | A filtering resolver may block known threats | Encryption alone does not identify every scam |
Your ISP or network operator can still observe connection metadata, such as destination IP addresses and traffic timing. Domain names may also be exposed through an unencrypted TLS Server Name Indication, depending on the connection. DoH alone does not solve those separate visibility issues.
Mozilla discusses network compatibility and remaining privacy limitations in its DoH FAQs. The important distinction is between hiding DNS query contents from an observer on the network and hiding your overall activity.
The piece that closes the SNI gap: Encrypted Client Hello
The SNI limitation mentioned above is worth following up on, because it has a direct answer now. The TLS handshake step that follows a DNS lookup, the ClientHello, has historically named the destination site in plain text even over an otherwise encrypted HTTPS connection; that unencrypted server name is the Server Name Indication this guide already flags as something DoH alone doesn’t protect. RFC 9849, standardizing Encrypted Client Hello (ECH), was finalized in March 2026, and encrypts that ClientHello so an observer on the path sees only a generic cover name rather than the real destination.
Chrome, Edge, Firefox and Brave enable ECH by default once encrypted DNS is in use, provided the destination site supports it; Safari is the notable holdout with no user-facing support yet. ECH needs the server side to cooperate too, so it isn’t universal: a site that hasn’t deployed ECH gives an observer nothing extra to hide behind, regardless of your browser settings. Treat DoH and ECH as a pair, not substitutes: DoH protects the lookup, ECH protects the connection name that follows it, and the SNI gap this guide flags above is the reason the second one matters.
DNS over HTTPS versus DNS over TLS and DNSSEC
These terms describe different protections, and understanding them makes provider settings easier to evaluate.
| Technology | Main purpose | Typical transport or scope |
|---|---|---|
| Traditional DNS | Resolve domain names and other DNS records | UDP or TCP port 53 without transport encryption |
| DNS over HTTPS | Encrypt the client to resolver DNS exchange | HTTPS, normally port 443 |
| DNS over TLS | Encrypt DNS using a dedicated TLS connection | TCP port 853 by default |
| DNSSEC | Authenticate signed DNS data through validation | Digital signatures rather than query encryption |
DoH wraps DNS in HTTPS. DoT uses a dedicated TLS transport, standardized in RFC 7858. Their shared aim is protecting DNS transport; neither is automatically the best choice for every network.
DNSSEC addresses a different question: can validated DNS data be trusted as authentic? It does not conceal the query. A resolver can validate DNSSEC while accepting your queries over DoH, so these protections can work together. Google explains resolver defenses in its DNS security documentation.
For a beginner, I would start with the encrypted DNS option supported by the device and network, then check the resolver’s validation and privacy policies. There is little value in choosing a protocol based only on an impressive acronym.
Is DNS over HTTPS the same as a VPN
No. DoH protects DNS exchanges. A VPN routes covered traffic through an encrypted tunnel to a VPN server and can change the public IP address that destination websites see.
The scope matters. Turning on browser DoH does not mean all applications use it. Similarly, a VPN may have split tunneling or application exclusions, so its coverage depends on configuration.
If you already use a business VPN, check its DNS guidance before selecting an unrelated resolver in the browser. Internal services may depend on the company’s DNS. Adding more privacy settings without understanding their interaction can create connection problems.
Google’s secure DNS transport overview is a useful reference for the DNS-specific layer.
How to enable DNS over HTTPS in Chrome
For desktop Chrome, follow Google’s current Secure DNS instructions:
1. Open Chrome Settings.
2. Select Privacy and security, then Security.
3. Find Use secure DNS under the advanced settings.
4. Enable it and choose the current provider option or an available custom provider.
Understand the fallback before you finish. Google says automatic mode can retry a failed lookup without encryption. When you select a custom provider, Chrome does not automatically fall back to unencrypted mode.
That means automatic mode favors continuity, while a custom provider can produce errors when its secure resolver is unavailable. Managed devices and parental controls can also restrict the feature.
Menu labels may change. If the setting is unavailable on a work computer, ask the administrator about the approved configuration.
How to enable DNS over HTTPS in Firefox
Use Mozilla’s current protection settings guide:
1. Open Settings, then Privacy and security.
2. Find DNS over HTTPS.
3. Open Advanced settings where shown.
4. Select a protection level and provider appropriate for your network.
Firefox’s Default protection allows fallback and responds to network conditions. Max Protection requires secure DNS and shows a warning when the secure lookup cannot be completed, with an option to create an exception.
Firefox also displays a DoH status such as Active, Not active, or Off. Check that status after changing the setting. Selecting an option is not the same as confirming that secure lookups are currently working.
On a managed network, use the organization’s policy rather than forcing a setting that breaks internal resources.
Which DNS over HTTPS provider should you choose
Choose based on privacy, reliability, filtering needs, and compatibility. A familiar brand name alone does not answer all four questions.
| Provider | Standard DoH endpoint | Useful distinction |
|---|---|---|
| Google Public DNS | https://dns.google/dns-query | Public resolver with documented DoH support |
| Cloudflare | https://cloudflare-dns.com/dns-query | Public resolver with browser and client setup documentation |
| Quad9 | https://dns.quad9.net/dns-query | Recommended service includes malware blocking and DNSSEC validation |
These are configuration endpoints, not ordinary pages to browse. Follow the format requested by your application; some clients use a URL template. Entering only a DNS server IP address does not, by itself, establish that DoH is enabled.
Check the official documentation for Google’s DoH endpoint, Cloudflare’s DoH service, and Quad9’s service addresses before configuring a custom client.
Read the provider’s privacy policy as well. DoH does not mean “no logs.” For example, Google Public DNS’s privacy policy explains its temporary and permanent logging categories. I would evaluate what is collected, why it is retained, and whether the policy fits the intended use.
How to check whether DoH is working
Start with the browser’s secure DNS configuration and any status indicator it provides. Then use a provider-specific test where one exists.
For Cloudflare, its connection verification guide points users to 1.1.1.1/help. Check the DoH result as well as the resolver connection result. This is a Cloudflare-oriented check, not a universal test of every provider.
A website that identifies your DNS resolver does not necessarily prove the transport was encrypted. Likewise, a browser test cannot confirm that a separate desktop application follows the same DNS settings.
For business deployment, my suggested acceptance test is practical: verify the secure DNS status, open public websites, check internal applications, connect the approved VPN, and confirm that required filtering still works. Record the results before extending the change to more devices.
Common DNS over HTTPS problems
Websites stop opening after a provider change
Recheck the provider selection or endpoint for errors. Compare several unrelated websites to determine whether the failure affects one domain or all lookups. Then check the provider’s service status and your network connection.
On a personal device, returning temporarily to the previous setting can help isolate the cause. Restore the intended secure configuration after troubleshooting; do not assume that a successful page load proves privacy protection has resumed.
Internal business websites stop working
A public resolver may not know a private company hostname or may return a different answer from internal DNS. This is common in split DNS environments.
Ask the administrator for the approved resolver, browser policy, or domain-specific exception. Guessing at public DNS settings can waste time when the required answer exists only inside the company network.
A public Wi-Fi login page will not appear
The network may require a captive portal sign-in before normal connectivity works. Complete the network’s legitimate sign-in process, then recheck secure DNS. Avoid entering sensitive account details into an unexpected portal.
Filtering behaves differently
Changing resolvers can change DNS-based blocking. Encryption and filtering are separate features: an encrypted resolver does not automatically preserve parental controls or the business’s malware-blocking policy.
Before rolling out a change, list the protections the existing resolver provides and confirm which ones the replacement supports.
Does DoH make browsing faster?
Not necessarily. Resolver location, cached answers, connection reuse, network latency, and packet loss all influence results. A faster DNS lookup also does not guarantee a faster complete page load.
Research comparing DNS, DoT, and DoH performance found that outcomes depend on network conditions. It is useful evidence against a universal speed claim, not a current benchmark ranking public providers.
My advice is to compare normal browsing on your own connection. Choose a stable setup that meets your privacy needs rather than chasing a single impressive test result.
What website owners need to know
Enabling DoH in your browser changes how your browser performs supported lookups. It does not automatically configure encrypted DNS for your visitors, install a website certificate, or repair your domain’s DNS records.
For a WordPress site, keep three tasks separate: maintaining accurate DNS records, securing the website with HTTPS, and configuring DNS privacy on the devices you control. My WordPress guides cover the website side, while my web development guides explore the wider technical foundations.
At Leelija, my company provides website, app, and software development services. The business principle I apply here is straightforward: define the actual problem before changing settings. A visitor’s DNS privacy, a broken domain record, and an insecure checkout require different work.
Should you use DNS over HTTPS?
For a personal browser on an unmanaged network, I generally recommend considering DoH with a provider whose policies you understand. Verify it works and decide whether you prefer fallback or an error when encrypted DNS is unavailable.
For a business network, make it a planned configuration change. Start with a small test group, check internal services and filtering, and document who owns the setting.
That is how I would make the decision: choose a clear privacy benefit, confirm that everyday work still functions, and avoid expecting one setting to solve every security problem.
Frequently asked questions
It is a way to send domain-name lookups through an encrypted HTTPS connection to a DNS resolver. It protects that exchange from network observers.
Public services such as Google Public DNS, Cloudflare’s standard resolver, and Quad9 offer free resolver options. Business filtering, reporting, or support products may have separate pricing.
DoH conceals the contents of the protected DNS exchange from an observer on that path. Other connection information remains visible, so it does not guarantee that your activity cannot be inferred.
Only if the selected resolver provides relevant filtering. DoH itself is an encrypted transport, not a malware-detection system.
There is no universal rule. Follow the VPN provider’s or employer’s DNS configuration guidance and test the actual setup, especially when accessing private business services.
Not automatically. Those addresses select resolvers; encrypted transport must also be supported and configured by the browser, operating system, or DNS client.