For filtering buyers, the most important encrypted DNS protocol is the one their real clients and networks can use reliably without losing policy identity or diagnostic evidence. DoH fits HTTPS-oriented clients, DoT offers a distinct TLS service, and DoQ uses QUIC. Treat protocol support as one requirement; verify resolver policy, roaming behavior, fallback, privacy, and operations separately.
There is no universal winner. A browser-heavy fleet, managed operating-system fleet, branch network, and embedded device estate can prefer different transports. Protocol buyer clarity comes from testing the complete path between a representative client and the policy resolver, not ranking acronyms by novelty.
Buy the resolver path, not an acronym
Define five requirements before reading a feature matrix: supported clients, networks crossed, resource identity, acceptable failure behavior, and diagnostic evidence. Add the privacy and retention boundary required by the organization or household. Then ask the provider to demonstrate each requirement on the transport the actual client will use.
Encryption answers one question: can an observer on the client-to-resolver path easily read or alter the DNS exchange? It does not decide which resolver the client trusts, which policy applies, how a resource is identified, or whether retained activity is protected. RFC 9076 treats DNS privacy as a system with multiple actors and observation points, not a transport checkbox.4
- Name the clients that must work, including browsers, operating systems, routers, and applications.
- Name the networks likely to constrain HTTPS, dedicated TLS, UDP, or QUIC traffic.
- Define how the resolver maps a request to the correct resource and policy without exposing reusable secrets.
- Define what happens when the encrypted endpoint is unreachable or its identity cannot be verified.
- Require evidence for an allowed result, blocked result, network transition, and failure case.
Compare three encrypted transports
DNS over HTTPS maps DNS exchanges onto HTTPS. RFC 8484 defines requests using HTTP methods and media types, so DoH can fit clients and environments already built around HTTPS.1 That can improve deployability, but it can also make the DNS path less distinct from ordinary web traffic. Buyers should ask how clients discover the endpoint, authenticate it, select policy, and report failures.
DNS over TLS sends DNS through a TLS-protected connection to a dedicated service. RFC 7858 specifies TCP port 853 as the default for DNS-over-TLS.2 The distinct service can make network intent and troubleshooting clearer, while networks that restrict that path can reduce compatibility. Confirm strict authentication and observed behavior; a nominally encrypted connection without verified resolver identity is not the same assurance.
DNS over QUIC carries DNS over a QUIC connection. RFC 9250 describes stream mapping and notes benefits such as encrypted transport and avoiding transport head-of-line blocking across independent streams.3 DoQ can be attractive where supported, but UDP or QUIC restrictions, middleboxes, client availability, and operational familiarity still matter. Do not infer a fleet outcome from a lab benchmark.
| Transport | Useful buyer question | Evidence to request |
|---|---|---|
| DoH | Do required clients support the approved HTTPS endpoint? | Endpoint identity, policy match, and failure result |
| DoT | Do networks permit and support the dedicated TLS service? | Authenticated connection and cross-network result |
| DoQ | Do clients and networks operate QUIC reliably? | Latency distribution, loss case, and fallback behavior |
Score client and network fit
Build a short coverage matrix using real fleet proportions. A protocol that serves ninety percent of important resources reliably may matter more than one that performs best on a small test subset. Include office, home, guest, cellular, captive-portal, and restricted-network contexts only when those contexts are genuinely in scope.
Inspect selection semantics as closely as transport support. A browser can choose an application-specific resolver rather than the system resolver; RFC 9076 discusses how this changes privacy and operational assumptions.4 A VPN can also own DNS inside its tunnel. Ask which control is authoritative, whether the client follows managed settings, and how split DNS or private names behave.
Do not reward silent downgrade. If the approved encrypted path fails, the client might fail closed, notify the user, retry, or use another resolver. Each behavior has availability and policy consequences. The right choice depends on the protected task, but it must be explicit, testable, and visible to the operator rather than hidden behind an “automatic” label.
Protect policy identity and evidence
A filtering service needs enough authenticated context to select the intended policy. Compare how each client path represents a household, team, network, or resource; how credentials rotate; and what happens when identity is absent or invalid. Reject designs that silently assign unknown traffic to a permissive shared policy or encode long-lived secrets in places users routinely expose.
The resolver necessarily processes live DNS requests to answer them and apply filtering. Retained activity is a separate decision. Ask whether detailed history is optional, how it is encrypted, who holds keys, which roles may access it, and how retention is bounded. Prefer aggregate health for routine operations and open detailed activity only for a named purpose and short window.
Keep DNS evidence modest. A lookup can be generated by a user action, application, advertisement, prefetch, update, or background process.4 DNS filtering can act on domain lookups and outcomes, but it cannot read page contents, search terms, in-app chats, voice audio, or full browser history. No encrypted DNS transport expands that visibility into content inspection.
Verify failure and roaming behavior
- Select one representative client for each protocol that is genuinely required.
- Confirm the endpoint identity, resource mapping, and effective policy before testing content categories.
- Run one provider-owned allowed hostname and one harmless blocked test hostname on the original network.
- Move to one materially different network and repeat fresh lookups without changing several settings.
- Make the encrypted endpoint unreachable and record whether the client fails, retries, or selects another path.
- Compare median and tail behavior, evidence quality, support effort, and privacy boundaries before deciding.
Document the winning client and network combinations rather than declaring one protocol globally best. An organization may standardize DoT for managed operating systems, support DoH for browsers, and postpone DoQ until client coverage justifies it. Another fleet may reach a different result. The decision is sound when every supported path has an owner, policy identity, failure contract, and repeatable acceptance test.
Encrypted DNS buyer questions
Is DoQ automatically more private than DoH or DoT?
No. All three can protect DNS traffic between the client and the selected recursive resolver. Privacy also depends on resolver choice, authentication, metadata, logging, retention, policy, and what happens after resolution. QUIC changes transport properties; it does not remove the resolver’s need to process the live query or guarantee better data practices.
Does encrypted DNS prevent a filtering resolver from applying policy?
No. Encryption protects the client-to-resolver transport. The selected resolver decrypts and processes the query so it can answer and apply its policy. Filtering is bypassed only when the client chooses a resolver or identity path outside the intended policy, not merely because the approved path uses encryption.
Should a buyer require DoH, DoT, and DoQ from day one?
Only when real client and network requirements justify all three. Broader protocol support can improve compatibility, but every path needs authentication, policy mapping, monitoring, failure behavior, and support documentation. Prefer two well-operated transports that cover the fleet over three checkboxes when the third path has no owner or acceptance test.
Evaluate one Veilty policy path
When evaluating Veilty, map the representative resource to its household Space or team Tenant and verify the effective reusable policy rather than assuming transport alone selects it. A resource may override baseline policy when permitted, but it cannot weaken enforced policy. Account membership grants no Space or Tenant access without an assigned scoped role. Retained DNS activity belongs to that boundary, is end-to-end encrypted with user-held keys, and is visible only through permitted roles, while the resolver necessarily processes live requests. Treat the required encrypted transports as buyer acceptance criteria, then verify one allowed result, one blocked result, and one failure path.