DNS over TLS: Resolver Privacy, Deployment, and Failure Boundaries
Understand how DNS over TLS changes resolver transport, how deployment differs from DNS over HTTPS, and what resolvers and proxies can still see.
BotBrowser Team
Want the structured docs for Network?
This article lives in the editorial library. For step-by-step setup, reference material, and ongoing updates, jump into the docs section.
DNS over TLS (DoT) is a DNS transport for a resolver path. A client opens a TCP connection to a resolver, negotiates TLS, then sends ordinary DNS messages inside that protected session. The standard service port is 853. This matters when a device owner needs a resolver relationship with explicit transport, certificate, and failure rules. It does not make a browser session anonymous, choose a proxy, or change what an origin site sees after the browser connects.
The important decision is not simply whether a lock icon appears beside a resolver name. A deployment needs to answer four questions: which component sends DNS, how it obtains the resolver address, which identity it authenticates during the TLS handshake, and what it does when that protected path is unavailable. Those questions place DoT chiefly in operating-system, network, router, forwarder, or dedicated resolver-client policy. That placement is different from a browser's HTTPS-based DNS setting.
DoT is a TLS session for DNS messages
RFC 7858 specifies DNS over TLS as a DNS-over-TCP connection protected by TLS. A server supporting the default arrangement listens on TCP port 853, and a client seeking privacy from that server connects to that port unless both sides have an agreement to use another port. The DNS question and answer retain DNS message semantics. TLS protects the channel used to carry those messages; it does not turn DNS into HTTP or change the records a resolver is expected to return.
Port 853 is a deployment signal, not a promise that every network will carry the traffic. A guest network, enterprise firewall, captive portal, or upstream provider can make a TCP connection to that port unavailable. A connection failure might occur before TLS begins, during the handshake, after certificate validation, or while waiting for a DNS response. These stages should be kept separate in documentation and diagnostics. A timeout to a resolver is not equivalent to an NXDOMAIN response, and neither proves why a network behaved that way.
RFC 7858 deliberately uses a dedicated port rather than upgrading an ordinary DNS connection in place. That makes the transport choice clear to both ends, but it also means a deployment must accommodate a distinct service path. A forwarder can maintain a TLS connection and send multiple DNS messages through it; a stub resolver can establish its own connection. The choice depends on where DNS policy belongs. It is not a browser-page permission and a website cannot reliably switch it on for a visitor.
The protocol still relies on a resolver. The resolver decrypts the message so it can answer the question. Encryption prevents observers that cannot terminate the TLS session from reading or changing the DNS message in transit, but the resolver operator can see the questions it serves and service metadata needed to operate that endpoint. Resolver selection therefore remains a trust and retention decision, even when transport encryption is working correctly.
Authentication is separate from encryption
TLS encryption and resolver authentication answer related but different questions. Encryption makes the bytes on an established TLS channel confidential to parties that cannot decrypt it. Authentication asks whether the client has connected to the intended resolver identity. A client that accepts a connection without a usable identity check may have encryption to some endpoint without the assurance that it is the configured service.
RFC 8310 describes an authentication domain name for a DNS server. That name gives the client an identity against which it can verify credentials such as a PKIX certificate. The resolver address and the resolver identity are not automatically the same thing. An IP address can change, a service can use multiple addresses, and several service names can be presented through shared infrastructure. A deployment should record the configured resolver name, the expected authentication domain name, and the certificate-validation policy rather than treating an address alone as a durable identity.
Certificate validation also needs an ownership boundary. A device administrator, resolver client, or operating system might manage trust anchors and policy. A user-facing application should not tell a person to ignore a certificate error or replace a managed trust decision merely to restore access. If the configured identity cannot be validated, the safe result depends on the selected privacy profile and the documented recovery path. It is not evidence that an unrelated origin site or proxy is at fault.
This distinction prevents a common overclaim. Saying that a resolver connection is encrypted does not mean that it is authenticated to the intended service, and saying that a certificate was accepted does not say who retains DNS data after the connection is established. The client needs all of: a selected resolver, a workable network route, TLS negotiation, identity validation where required, and a resolver response. Each layer can fail or be owned by a different party.
Strict and opportunistic privacy make different promises
RFC 8310 defines Strict Privacy and Opportunistic Privacy profiles. Strict Privacy requires an encrypted connection and authenticated server identity for the selected resolver. It is appropriate when the requirement is specifically to use an identified protected resolver service. If that authenticated path is unavailable, a strict deployment should report the condition and follow its preselected recovery policy rather than silently treating an arbitrary ordinary resolver as equivalent.
Opportunistic Privacy attempts to improve transport protection but allows outcomes with weaker assurance when the ideal protected, authenticated connection cannot be obtained. The RFC describes this as a transition-oriented profile with varying protection properties. It should not be described as a guarantee that every DNS message is encrypted and authenticated. Its availability advantage is a policy tradeoff, not proof that the fallback has the same privacy properties as a strict resolver path.
The label a product uses may not exactly match the RFC terms. A device interface can offer automatic, private, secure, or provider-specific choices, while its underlying resolver policy decides whether it is using a strict requirement, an opportunistic attempt, or another arrangement. Read the documentation for the specific client and release. For example, Android's Private DNS guidance documents device settings rather than a browser-only control. A setting at that layer can affect applications that use the system resolver, subject to device and network policy.
Choose the profile before testing failure behavior. A managed service that requires an approved resolver identity needs a documented stop or recovery procedure. A consumer device may decide that continued resolution through an ordinary path is acceptable when encrypted resolution is not available. Neither answer is universal. What matters is that the profile, allowed fallback, and support owner are stated in terms a user can understand.
Bootstrap and resolver placement need explicit ownership
A DoT client often needs an address before it can connect to the protected resolver. That creates a bootstrap question: how does the client obtain the resolver address and authentication domain name without assuming that the protected session is already available? RFC 8310 discusses sources for authentication domain names and the conditions surrounding use of a resolver address. A deployment should document the bootstrap source, the selected identity, and who updates that configuration.
Bootstrap is not a defect in DoT. It is a boundary to model honestly. A device can receive resolver configuration from a network, use an administrator-provided endpoint, rely on a local forwarder, or use a resolver client with its own policy. The initial lookup or configuration fetch may not have the same protection properties as later DNS messages inside the TLS session. A reader should not infer from a protected steady-state connection that every configuration or address-discovery step was protected in the same way.
Placement determines scope. A router or local forwarder can send upstream DNS over TLS for several devices while the devices use ordinary DNS to the local service. An operating system can implement a protected resolver policy for applications that ask its resolver. A dedicated client can apply only to the software configured to use it. A browser can instead use an HTTPS DNS feature that is independent from the system resolver. These are different deployment shapes, even when the same resolver company is involved.
This scope difference is why DoT should not be described as a browser privacy toggle. A browser's Secure DNS help describes browser behavior for its HTTPS-based feature, while a device DoT setting is owned below the browser. A browser page cannot discover every resolver path used by the device, and a system DoT policy does not automatically establish what a proxy resolves. Name the component that performs the lookup for the traffic being discussed.
A proxy does not become a DoT resolver
DNS resolution and proxy routing are separate functions. A resolver answers a DNS question. A proxy carries an application connection and, depending on its protocol and configuration, can receive either a hostname or an address. If a client resolves a hostname before it opens a proxy connection, the resolver path happens first. If a proxy receives a hostname and resolves it remotely, the proxy operator chooses or operates the resolver path for that connection. DoT on a device does not force either arrangement.
The observable parties are therefore different. A DoT resolver can see the name it is asked to resolve. A proxy can see the connection it carries and the records its own service creates. The destination can see the connection and request it receives, including cookies, headers, and account state. The network path to a protected resolver cannot read the DNS message when TLS is correctly established, but the later destination connection remains a distinct event. DoT does not hide a destination from itself or remove account identifiers.
BotBrowser can route browser traffic through supported proxies. Its proxy configuration is not a DoT switch and does not change the operating system's resolver policy. When a workflow uses both, document the proxy scheme and the DNS owner independently. The BotBrowser proxy configuration guide explains the supported proxy route; the DNS decision still belongs to the browser, proxy, device, or resolver client that performs the lookup.
This separation is especially useful when debugging. A successful DNS answer does not prove that a proxy accepted a connection. A proxy failure does not prove that certificate validation for DoT failed. A destination error does not identify a resolver. Preserve these stages in support messages so that a person can take the next permitted action without disclosing a browsing history or drawing conclusions from timing alone.
Plan availability and timeout behavior before rollout
DoT fails in ordinary ways: a resolver endpoint can be unreachable, TCP 853 can be filtered, a TLS handshake can fail, the expected certificate name can be absent, a captive portal can prevent normal traffic, or the resolver can return an ordinary DNS error. These conditions require different handling. A client should expose a clear failure stage while keeping user input and the task state intact when possible.
For Strict Privacy, a certificate mismatch or unavailable authenticated endpoint means the required condition was not met. The documented response might be to stop network-dependent work, offer an offline action, or direct an authorized administrator to restore the configured service. It should not silently replace the known identity with an unapproved endpoint. For Opportunistic Privacy, the allowed fallback must still be described as a lower-assurance path, not as indistinguishable secure DNS.
Timeouts need a limit. Repeated background retries can delay applications and create noisy records without adding useful evidence. A bounded retry, a visible resolver-unavailable state, and a recovery instruction are easier to support. Diagnostics can retain the failure stage, client version, policy state when the person is authorized to share it, and a controlled test name. They usually do not need a list of real hostnames a person tried to visit.
Captive portals are a practical example. Before a device completes a network sign-in, a network may prevent the resolver route needed by a protected configuration. The right recovery is to follow the device or network's documented sign-in path, then retest the approved resolver route. A portal is not proof that a resolver is malicious, and it does not justify changing an administrator-owned setting without authorization.
Validate a deployment without making broad claims
Start with configuration evidence. Record the resolver endpoint or address, authentication domain name, selected profile, client and operating-system version, and the owner of the policy. Check that the configured resolver identity appears where the client documents it. On a managed device, use the management or device reporting surface available to the owner rather than relying only on a screenshot of a browser menu.
Then use controlled names and endpoints. A test domain owned by the organization can distinguish an expected DNS answer from a transport failure without collecting a person's normal query history. Test a normal answer, a name that intentionally has no record, an unavailable endpoint, and a certificate or identity condition in an authorized test environment. Record whether the client showed the expected stage and followed the configured profile. Do not convert a single test result into a claim about every application or every network.
Test the proxy path separately. Determine whether the client hands the proxy a hostname or an address for the connection under test, then compare that behavior with the chosen DNS owner. A result from a DNS test service can describe the lookup used for its own controlled hostname; it cannot prove that all background requests use the same path or that a resolver retains no data. The DNS leak prevention guide covers the adjacent proxy-route consistency question.
Finally, state the result narrowly. A support note can say that a named device or resolver client, at a recorded version, used its configured strict or opportunistic policy for controlled checks. It should separately note any permitted fallback and the fact that proxies, origins, account state, and other applications remain outside the result. This statement is testable and avoids turning encrypted DNS transport into a blanket privacy claim.
Choosing the right deployment layer depends on who needs to own the resolver path. Use DoT when the owner needs a transport policy at the device, local-forwarder, router, or resolver-client layer and can manage endpoint identity and fallback. It can fit a fleet where an administrator owns the resolver contract, or a local forwarder that consolidates upstream DNS behavior. It is less suited to a claim that only one browser tab has changed, because the browser may not be the component that opens the DoT connection.
Use a browser's documented HTTPS DNS feature when the intended scope is a browser profile and the browser exposes the needed policy. That is a different deployment choice, not a replacement name for DoT. The DNS over HTTPS browser controls guide explains HTTP request semantics and browser-managed controls. Comparing the two protocols is useful only when it identifies the owner, endpoint, trust model, and fallback behavior for the actual environment.
For any layer, assess the resolver operator's published retention, incident, and support practices. TLS changes what on-path observers can read, but it does not remove the resolver as an observer. Also assess whether the chosen layer covers the applications that matter. A device setting may not cover a proxy's remote resolution, and a browser setting may not cover the operating system or another application.
The durable promise is specific: a selected component sends DNS over a TLS-authenticated resolver path under a documented profile, subject to the tested device and network conditions. It is not a promise of anonymous browsing, universal encrypted DNS, or a route chosen by every application on a machine.
Connection reuse does not remove these boundaries. A long-lived TLS session can reduce repeated handshake work, but the client must still handle closure, a changed resolver address, certificate expiration, and network movement. Record whether a controlled check created a session, received a DNS answer, or reached a later application destination. Those observations describe the tested stage only. They do not reveal every resolver decision on the device, establish a provider's retention practice, or prove a future network will accept TCP 853.
Review the result after policy changes, resolver migrations, operating-system upgrades, and a move between managed and unmanaged networks. Each change can alter the component that owns the resolver route.
Sources
Related Articles
Take BotBrowser from research to production
The guides cover the model first, then move into cross-platform validation, isolated contexts, and scale-ready browser deployment.