DNS over HTTPS: Browser Privacy, Controls, and Resolver Limits

DNS over HTTPS, usually shortened to DoH, carries a DNS message in an HTTPS request to a DNS resolver. It can keep that DNS exchange from being read or modified by an observer on the path between the browser and the chosen resolver. It does not make a browsing session anonymous, move a connection through a proxy, or tell a website which resolver answered a name. The useful question is narrower: which browser traffic is covered by the browser's secure-DNS setting, who operates the resolver, and what happens when that setting cannot be used.

That distinction matters because DNS is only the naming step. A browser resolves a hostname, opens a connection, and sends an HTTP request. Those steps can involve a browser setting, an operating-system resolver, a proxy, and a destination service with separate operators and logs. DoH changes one transport segment in that chain. It is valuable when that segment is the one a reader intends to protect, but it is not a substitute for a complete route or data-retention design.

The HTTP exchange DoH actually changes

The DNS protocol maps a name such as www.example.test to records that a client can use. With ordinary DNS, a client commonly sends that question to a resolver over UDP or TCP. With DoH, RFC 8484 maps one DNS request-response pair to one HTTP exchange. The interoperable media type is application/dns-message, carrying a DNS message in the normal DNS wire format. The browser still needs a resolver that can read the question and create the answer; HTTPS does not encrypt the question from that resolver.

RFC 8484 permits both GET and POST. A GET request puts the DNS wire message in a dns URI-template parameter after base64url encoding. A POST request sends the DNS message as the request body with Content-Type: application/dns-message. The protocol defines both forms so an endpoint can support the request shape it advertises. A person selecting a secure-DNS provider normally chooses a browser provider entry or endpoint rather than constructing either request form by hand.

The distinction still has operational consequences. GET can work well with HTTP caches because equivalent request URIs can be recognized by cache infrastructure. A URI also places the encoded DNS request in the request target seen by the DoH service and any intermediaries that handle that request. POST keeps the DNS message in the body, but it is not a promise that the resolver cannot log it. Both methods deliver a DNS question to the resolver. Neither method converts a DNS answer into a privacy guarantee for later page requests.

Caching is part of the standard's model, not a workaround for failed privacy. RFC 8484 says a DoH exchange can pass through a hierarchy of caches, and DNS response TTLs remain relevant to how long an answer can be used. A browser can therefore have a usable cached address even while a fresh DoH request is unavailable. Conversely, a successful HTTPS status does not mean the DNS question succeeded: the RFC uses a successful HTTP status for a valid DNS response even when that response carries a DNS failure such as NXDOMAIN or SERVFAIL. A troubleshooting screen should distinguish an unavailable secure-DNS endpoint, a DNS negative answer, and a failed connection to the destination instead of turning all three into the same message.

DoH is different from DNS over TLS because it uses HTTP semantics and an HTTPS endpoint. That can make it fit browser settings and web-style infrastructure, while DNS over TLS is typically configured as a device or resolver-client transport. The difference does not decide which operator sees a name. The DNS leak prevention guide covers the adjacent question of who resolves names when a proxy is also present.

Browser controls are product-specific controls

A web page cannot turn DoH on for a visitor and cannot use a portable web API to prove that DoH was used for its own hostname. The browser, its profile, a device administrator, and sometimes the operating system own that decision. Browser labels and defaults also change over time, so support material should name the product and version being discussed rather than describe a generic "DoH switch."

Firefox's DNS over HTTPS support page documents browser-facing protection choices and provider configuration. The visible choices can differ by release, region, installed policy, and platform. A reader should use Firefox's current Settings page and its documentation together: the setting describes the protection mode in that browser profile, while a managed device can constrain what may be changed. Treat a selected provider as an instruction to Firefox, not evidence that every application on the device adopted the same resolver.

Chrome's Secure DNS help documents a different user-facing model. Chrome says Secure DNS is on by default in automatic mode and that, if lookups have problems in that mode, Chrome looks up the site using unencrypted DNS. That is a deliberately limited promise: automatic mode can retain availability, but it cannot be described as a strict guarantee that every lookup stays encrypted. The same help page says the feature cannot be used when the device is managed or parental controls are enabled. A user-facing check must therefore first establish whether the setting is available and managed before treating a menu choice as a local preference.

Custom-provider language also needs care. A browser may allow a person to select a provider or enter an endpoint template, but the endpoint must be a genuine DoH service and its operator becomes a resolver observer. The browser's provider label does not show the provider's retention policy, upstream arrangement, account relationship, or service availability. Read the provider's own published terms before making a governance decision, and do not present an endpoint name as a measure of anonymity.

One observable check is modest but useful. Open the documented browser settings on the exact profile in use and record the displayed secure-DNS mode, provider selection if visible, and whether the control is administrator-managed. This verifies the configuration the browser exposes. It does not verify every DNS transaction, identify the resolver from a web page, or prove what an operating-system service did outside that profile.

Managed Chrome policies set mode and templates separately

Organizations often need an outcome that is more specific than a user toggle. Chrome Enterprise documents the DnsOverHttpsMode policy and lists the values off, automatic, and secure. It also documents DnsOverHttpsTemplates, a policy for the URI template of a desired DoH resolver. These are separate controls: the mode expresses how Chrome should approach secure DNS, while the template supplies an endpoint form for a configured resolver. An administrator should set and test both according to the organization's intended mode instead of assuming that a template alone expresses a strict-routing requirement.

The policy reference is versioned by Chrome support and platform. Its current listing shows DnsOverHttpsMode support beginning with Chrome 78 on desktop and Android, while DnsOverHttpsTemplates has its own listed platform support. Check the deployed browser version and the current Chrome Enterprise policy reference before relying on these names; do not infer that every Chrome-based product exposes the same behavior. A managed configuration can refresh, and a locally visible setting can be unavailable because a higher-level policy owns it.

For a managed fleet, state the intended behavior in plain terms. For example, "automatic mode may use the current resolver path when secure lookup cannot be used" is materially different from "secure mode with an approved template is required for this browser." The right wording depends on the policy the administrator deployed and the browser version that was tested. Neither wording should claim to govern DNS requests issued by other applications, a proxy server, or a device service outside Chrome.

The practical administrator check is to inspect the policy reporting surface provided by the managed browser or management system, then compare the reported mode and template with the documented configuration. Test with a controlled hostname that the organization owns, an ordinary resolvable hostname, and an intentionally unavailable condition in a test environment. The result should be recorded as the browser behavior observed for that version and policy, not generalized into a claim about all networks or all future releases.

Browser DNS, operating-system DNS, and proxies are separate paths

The flow diagram has two paths because name resolution and the subsequent connection are different jobs. A browser-side DoH setting can send a DNS message from that browser profile to its DoH resolver. The operating system may still resolve names for other browsers, background services, or applications that do not use that setting. Conversely, an operating system can have its own DNS policy while a browser uses a separate secure-DNS feature. Do not use a browser setting as evidence that the entire device changed resolvers.

A proxy is a third role. It carries an application connection and may receive either a hostname or an address depending on the proxy scheme and browser configuration. In some arrangements, the browser resolves a name before contacting the proxy. In others, the proxy resolves the hostname on its side. Those cases change who receives the DNS question, and the exact ordering is implementation- and policy-dependent. Enabling DoH does not by itself force proxy-side resolution, and choosing a proxy does not by itself enable DoH.

This is why a route needs named owners. The DoH resolver can see the question it receives and metadata needed to provide the service. A proxy can see the connections it carries and the information its own service logs. The destination sees the connection and request that reach it, including application-level identifiers such as cookies, headers, or an account session. HTTPS between a browser and a DoH endpoint protects that DNS exchange from observers that cannot terminate it; it does not conceal the later connection from the destination or erase records created by the resolver or proxy.

BotBrowser can route browser traffic through supported proxies. Its proxy configuration is not a DoH control and does not change the operating system's resolver policy. A workflow that needs both a proxy route and a particular DNS arrangement should verify those decisions separately against the supported proxy configuration and the browser or device documentation. The BotBrowser proxy configuration guide and proxy, DNS, and WebRTC consistency guidance describe adjacent routing boundaries without making a per-context DoH claim.

Captive portals make this separation visible. A hotel, airport, or guest network can require a device to reach a sign-in page before ordinary Internet access works. A browser may need a network-specific path to discover or complete that access, and secure-DNS behavior can be limited by network conditions or browser policy. A failed lookup on such a network is not evidence that a resolver is malicious and is not a reason to override an administrator's setting. It is a condition to explain, recover from according to the documented browser behavior, and retest after access is established.

DoH has clear privacy limits and failure boundaries

DoH can reduce exposure to a local observer that would otherwise read or alter plaintext DNS traffic. The resolver remains able to read the question because it must answer it. The later destination connection still reveals an address to the network path and a request to the destination service. Cookies, storage, referrers, permissions, account sign-in, analytics, and embedded resources can also carry context unrelated to DNS. A claim such as "private DNS makes browsing private" is therefore too broad to be useful.

Resolver visibility is not a defect in the protocol. It is the service relationship a reader chooses. Evaluate a resolver by asking who operates it, which policy or account selects it, what its published retention and incident practices say, and whether its reliability model fits the intended browser use. Encryption in transit changes which on-path observers can read the DNS message; it does not make the resolver unable to observe its own service.

Fallback behavior belongs in the same decision. Chrome's documented automatic mode is one example of a mode that may use unencrypted DNS when secure lookup has problems. Firefox and other browsers expose their own modes and managed-policy interactions. A device can also have an operating-system resolver path that is outside the browser setting. For a task where availability matters, the reader should know whether an ordinary fallback is acceptable. For a task that requires an approved resolver, the owner may choose to stop before sending the application request when that resolver cannot be used. The correct outcome depends on the stated requirement, not on a universal rule that encrypted DNS must always win over access.

Avoid silent changes to an unapproved provider. A visible failure can be more honest than a route that quietly changes its resolver. At the same time, a resolver error message need not store a person's full query history. A support record can retain a short-lived stage such as secure-dns-unavailable, browser version, policy state when authorized to share it, and the time of a controlled reproduction. Use organization-owned test names when a hostname is needed. That provides a useful diagnostic boundary without treating a DNS event as a profile of the reader.

Web applications should also remain humble about what they can observe. A page can see that its own request failed, timed out, or succeeded. It cannot infer from that outcome which resolver answered the name, whether a cache supplied an answer, or whether an HTTPS DNS request was used. Timing is not an authoritative resolver signal. A site should not build identity or access decisions from guessed DNS paths.

A practical, bounded way to check the configuration

Start with the browser interface rather than a network guess. On the exact browser profile, find the vendor's documented secure-DNS setting. Record the visible mode, selected provider or system-provider option, browser version, and whether the control is managed. On Chrome, distinguish automatic mode from a mode intended to require a configured provider. On Firefox, use the protection mode names shown by that release rather than mapping them to Chrome terminology. This is a configuration check, not proof of every packet path.

Next, identify the route outside the setting. Decide whether the browser uses a proxy, whether the proxy receives hostnames or addresses for the relevant connection, and whether the operating system has a separate DNS policy. A resolver test service or an organization-owned authoritative test domain can provide limited evidence about a test lookup, but it sees only the names used by that test. A clean result does not establish anonymity, show every background lookup, or reveal what a resolver retained. Repeat the controlled check after changing the browser version, policy, proxy scheme, or network environment.

Then exercise a failure condition that is safe for the environment. A controlled DoH endpoint can be made unavailable in a test setup, or a device can be tested on a network with a known portal. Observe the browser's visible error or documented fallback behavior and verify that an application preserves user input where appropriate. Do not use a person's normal browsing history as test material, repeatedly retry an unknown route, or interpret an outage as a trust signal about a network actor.

Finally, write the operational promise at the level the evidence supports. A sound statement might say that a specified browser profile is configured to use its documented secure-DNS mode with an approved provider, subject to the browser version and any managed policy. It should separately state the fallback behavior that has been accepted and the fact that system DNS, proxy resolution, and destination connections remain separate paths. That is more useful to a reader than a blanket privacy claim because it says what can be checked and what still needs its own decision.

Choosing a resolver responsibly is both a technical and a governance decision. Compare the provider's published operating policy, retention explanation, incident process, and support model. An encrypted request can still give the resolver the queried name, request timing, and network information needed to answer it. Choose an endpoint whose operator and support obligations are clear instead of treating a familiar provider label as proof of privacy.

A personal browser profile may follow the person's documented preference. A managed profile may require an organization-approved endpoint and a policy notice. A test profile should use a controlled hostname and an endpoint that the test owner can explain. Keep the provider choice separate from application identity; a site should not require one resolver for sign-in unless that dependency is an explicit, reviewed requirement.

Availability belongs in the provider decision. A resolver can be reachable from one network and unavailable from another, or a policy can prevent a user from changing it. Record the approved alternative and the owner who can change the policy. Do not ask a person to weaken an administrator setting for an unrelated task.

Fallback paths and controlled tests

Secure-DNS settings can have more than one path. A browser may try a configured endpoint, use another resolver when an automatic mode permits it, or honor an administrator's disablement. Some networks intercept the first connection for captive-portal access, and some operating systems centralize DNS policy below the browser. These conditions are reasons to describe the tested contract carefully, not reasons to assume every lookup used DoH.

Build a small outcome matrix around a normal configured endpoint, an unavailable endpoint, a managed policy that prevents changes, a proxy that performs its own resolution, and a destination that deliberately fails. For each case, check that the visible message is accurate, entered data is preserved, and the next action is clear. Use browser and operating-system versions that the product actually supports.

Use domains and endpoints owned by the test team. A controlled endpoint can return an expected answer, delay the response, or close a connection so fallback behavior is observable without recording a person's real queries. Keep fixture names out of production analytics and expire test records after the run. A test should not depend on a provider IP or resolver latency that can change.

Review positive and negative assertions together. It is useful to verify that an approved endpoint is reached in a managed test environment when that evidence is available. It is not useful to assert that a public page can identify every resolver or that a timeout proves a particular network actor. Network timing varies, so it is not a privacy or trust boundary.

When a browser update changes a default, the same profile can take a different path without an application code change. Recheck the visible mode after browser and operating-system upgrades, and record the version alongside the result.

A policy report is stronger evidence than a screenshot of a menu. A screenshot can show what a user sees, while a management report can show whether an administrator imposed the mode or template. Use the evidence appropriate to the owner of the setting.

The resolver choice should not be hidden in a deployment script. Support staff need a documented provider class, mode, and recovery rule so that a failure can be explained without asking a user to disclose unrelated browsing details.

DoH does not cover every hostname a device may resolve. Background applications, update services, and another browser can use the system resolver even while one profile uses secure DNS. Scope statements should name the browser and profile.

An origin can still identify a visit through account state, cookies, or application headers. A secure-DNS check cannot validate those separate privacy surfaces, so review them with the controls that own them.

An approved resolver can be unavailable for ordinary reasons such as a certificate problem, a captive portal, or a policy refresh. A visible stage and bounded retry are more useful than a diagnosis that assigns intent to the network.

Cache behavior can make two identical navigations take different paths. A first request may contact the resolver while a later request uses a cached answer. Controlled checks should use fresh, organization-owned names when that distinction matters.

GET and POST describe the HTTP shape of the DNS exchange, not two different privacy levels. The resolver receives the DNS question in either case, and the service's retention policy remains relevant.

The destination connection can be direct or proxied after resolution. DoH does not select the proxy and a proxy does not tell the browser which DoH endpoint to use. Document both decisions separately.

A useful incident record can say secure-dns-unavailable without including the full queried hostname. Add a hostname only for an approved controlled reproduction, then expire that evidence according to the team's retention rule.

The strongest reader promise is therefore specific: name the browser, mode, provider class, tested version, and accepted fallback. State which device, proxy, resolver, and destination observers remain outside that promise.

That wording keeps the control useful without claiming that one browser preference governs the whole network.

Sources

• RFC 8484: DNS Queries over HTTPS
• MDN: DNS
• Firefox: DNS over HTTPS
• Chrome: Manage Chrome safety and security