What are the trade-offs between using DoH/DoT, DNSCrypt, and a local recursive resolver for privacy?

1. The protocol-level trade: standardization, transport, and visibility

DoT (DNS-over-TLS) and DoH (DNS-over-HTTPS) are standards-track protocols with RFCs and broad support; DoH tunnels DNS inside normal HTTPS traffic on port 443 making it hard for network middleboxes to distinguish and block, while DoT uses a dedicated TLS port that preserves operator visibility and filtering capability ^{[3] [1]}. DNSCrypt predates these efforts and authenticates/encrypts the client–resolver channel, but it has not been standardized by the IETF which has led to inconsistent implementation and lower mainstream adoption ^{[1] [2]}.

2. Privacy: who sees your queries, and when

All three encrypted transports (DoH, DoT, DNSCrypt) protect the client–resolver hop from eavesdroppers and local man‑in‑the‑middle attacks, but none encrypt the resolver’s downstream queries to authoritative servers — those remain in the clear unless additional measures (like DNSSEC for integrity or privacy-focused resolver chains) are used ^{[2] [1]}. That means choosing an encrypted transport mostly protects against on‑path local observers; it does not eliminate visibility at the resolver or at authoritative nameservers ^[2].

3. Trust and control: cloud resolver vs local recursion

Using a cloud DoH/DoT/DNSCrypt resolver delegates query logs and policy control to that provider: you gain convenience and less local exposure but transfer trust and telemetry to the provider (noted across discussions favoring DoH/DoT for privacy advocates while warning about shifting control to browsers and cloud providers) ^{[4] [3]}. Running a local recursive resolver gives you maximum control over who sees queries and lets you avoid sending plaintext to a third‑party resolver, but it requires expertise, upkeep, and still causes plaintext queries to authoritative servers beyond your network (available sources do not mention detailed operational burdens of local recursion beyond implied maintenance; p1_s2).

4. Blocking, enterprise policy, and network management

DoT’s dedicated port makes enterprise and ISP filtering and monitoring straightforward; network administrators can continue to apply DNS‑based security controls. DoH, by blending into general HTTPS flows, makes such controls harder without blocking all HTTPS to a resolver — a behavior Cloudflare and others explicitly call out when contrasting DoH and DoT ^[3]. DNSCrypt can run on different ports and be made hard to block in some setups, but lack of uniform standards affects predictable enterprise deployment ^{[5] [1]}.

5. Implementation and ecosystem realities

DoH and DoT benefit from wide library and browser/OS support (Firefox, Windows support patterns, major public resolvers like 1.1.1.1 support both), which improves compatibility for end users; privacy advocates often favor DoH or DoT for protecting the client–resolver link ^{[4] [3]}. DNSCrypt has multiple implementations and public servers and can be combined with other privacy tools, but its non‑IETF status has limited adoption compared with the standardized options ^{[1] [5]}.

6. Performance, feature gaps, and future directions

Community threads and vendor guides record mixed performance anecdotes (some users report DoT latency impacts, others prioritize newer transports such as DoQ/DoH over DNSCrypt), and standards work continually evolves the space — RFCs, new transports, and experimental approaches affect practical trade‑offs ^{[6] [1]}. Available sources do not provide exhaustive benchmark data comparing latency or CPU costs across DoH/DoT/DNSCrypt versus local recursion; those details are not found in current reporting ^{[6] [1]}.

7. Practical recommendation framework

If you want easy, standardized encryption with broad client support and little setup, choose a reputable DoH/DoT provider — but accept that the provider sees your queries and that downstream authoritative lookups remain unencrypted ^{[3] [2]}. If you prioritize minimizing third‑party visibility and are willing to operate services, run a local recursive resolver — but be prepared for maintenance and for the authoritative leg to be in clear (available sources do not detail local‑resolver operational checklists) ^[2]. If you need channel authentication and flexible deployments and are comfortable with less mainstream tooling, DNSCrypt remains a viable option, albeit with fewer guarantees of consistent behavior across the ecosystem ^{[1] [5]}.

Limitations: this summary is built from the provided sources and focuses on protocol-level trade‑offs and common community perspectives; it does not include independent performance testing or exhaustive operational guides, which are not present in the supplied reporting ^{[2] [1]}.