why and for what purpose?

[SergioSikoni]

Hello, why do I need a DNS script if there are, for example, DNS over TLS and DNS Over https? What's the advantage? After all, dot and doh also encrypt traffic. Could you provide a link to download the Android app?

[jedisct1]

Abstract

This document provides a technical comparison between DNSCrypt, DNS over TLS (DoT), and DNS over HTTPS (DoH).
While DoT and DoH are standardized by the IETF, DNSCrypt—now also formalized as an IETF draft—continues to demonstrate superior technical properties:

• No insecure bootstrap procedure
• Lower latency and higher efficiency, even versus DoH over QUIC
• No dependence on the global TLS Public Key Infrastructure (PKI)
• True decentralization (no corporate control)
• Flexible and extensible protocol design
• Built-in authenticity and optional anonymization

This paper argues that DNSCrypt remains the most secure, efficient, and independent approach to encrypted DNS, while DoH and DoT suffer from structural and political limitations inherited from the web ecosystem.

---

1. Introduction

The Domain Name System (DNS) remains a foundational Internet service—but also one of its greatest privacy weaknesses.
Traditional DNS operates entirely in plaintext, allowing ISPs, governments, and intermediaries to log or manipulate user queries.

Over the past decade, multiple encrypted DNS protocols have emerged:

Protocol	Year	Standard	Transport	Layer
DNSCrypt	2011	IETF Draft (2025)	UDP/TCP	Custom
DoT	2016	RFC 7858	TCP	TLS
DoH	2018	RFC 8484	TCP/QUIC	HTTPS

DoT and DoH were introduced to integrate encrypted DNS into the TLS/HTTP ecosystem.
However, these protocols inherited the same trust model, performance overhead, and centralization risks as HTTPS itself.

DNSCrypt, in contrast, was engineered from first principles—to be fast, cryptographically authenticated, censorship-resistant, and independent of the CA system.

---

2. The Bootstrap Problem

2.1 DoH/DoT Bootstrapping

DoH and DoT clients typically reference resolvers by hostname (e.g., dns.example.com).
To establish an encrypted connection, they must first resolve this hostname using plaintext DNS.

This circular dependency creates serious issues:

• Insecurity: The bootstrap query is unencrypted and observable.
• Leakage: The resolver’s identity and user intent are exposed before encryption begins.
• Fragility: If the bootstrap fails or is hijacked, encrypted DNS cannot start.
• Complexity: Workarounds (IP pinning, fallback resolvers, static configuration) increase maintenance overhead.

In short, DoH/DoT depend on an insecure foundation for their initial connection.

2.2 DNSCrypt: No Bootstrap Needed

DNSCrypt clients are configured with:

• The IP address of the resolver, and
• Its public key.

These are distributed in signed resolver lists such as public-resolvers.md, verified locally using strong cryptographic signatures.

Thus, DNSCrypt can send its very first packet already encrypted and authenticated, with no dependency on insecure DNS or PKI lookups.

✅ Result:
DNSCrypt starts encrypted, verified, and private from the very first query.

---

3. Protocol Design and Extensibility

3.1 DoT: Rigid and Hard to Evolve

DNS over TLS (DoT) was designed as a minimal wrapper: DNS inside a TLS session.
However, this design is inflexible and hard to extend.

For instance:

• DoT forgot to include padding in its specification.
• When padding was later needed for traffic analysis resistance, it had to be implemented inside DNS itself via a new RFC (RFC 8467).
• This introduced extra bandwidth and inefficiency, because padding could not be handled at the transport level.

In other words, DoT is frozen around TLS’s limitations—every improvement requires new DNS-level hacks or complex RFC layering.

3.2 DoH: Even Heavier, HTTP-Bound

DoH tunnels DNS inside HTTP requests, which are then wrapped in TLS or QUIC.
This means that DNS messages must go through:

• HTTP framing,
• Header parsing,
• TLS handshakes,
• Optional QUIC connection management.

While this improves “integration” with browsers, it massively increases overhead.
DoH’s complexity also ties DNS privacy to browser vendors and CDN operators, who dominate HTTPS infrastructure.

3.3 DNSCrypt: Modular and Future-Proof

DNSCrypt was designed as a standalone encrypted DNS protocol—simple, efficient, and extensible.

It supports:

• Built-in query padding,
• Multiple crypto suites (including X25519, Ed25519),
• Anonymized DNS relays (for IP-level privacy),
• Custom transport options (UDP, TCP, relays, etc.),
• Filtering and rewriting capabilities at the proxy level.

Adding new features (like new ciphers or padding rules) requires no protocol redesign or cross-layer dependencies.

✅ Result:
DNSCrypt evolves naturally, while DoT and DoH are stuck within TLS/HTTP constraints.

---

4. Security Model and Trust

4.1 TLS PKI: The Weak Link of DoT and DoH

DoT and DoH rely on the global web PKI.
Any trusted Certificate Authority (CA)—there are hundreds worldwide—can issue a certificate for a DNS resolver.

This introduces multiple risks:

• State-level interception: Governments can coerce domestic CAs.
• Corporate interception: Enterprises deploy TLS-inspection gateways with custom CAs.
• Misissuance: History shows repeated CA compromises or accidental certificate leaks.

This means control over DoH/DoT traffic can be exerted by:

• CA operators,
• CDN providers,
• Enterprise network policies,
• And even national firewalls.

4.2 DNSCrypt: Dedicated Keys, No CA Dependency

DNSCrypt eliminates the CA system entirely:

• Each resolver has its own static public key.
• Clients verify this key directly through cryptographic signatures, not a CA chain.
• There is no external trust anchor or certificate hierarchy to compromise.

Resolvers cannot be silently hijacked or spoofed without detection.
The trust model is compact, local, and verifiable.

✅ Result:
DNSCrypt is cryptographically self-verifying and resistant to institutional control.

---

5. Centralization and the CDN Problem

DoH was heavily promoted by major Content Delivery Networks (CDNs) such as Cloudflare and Google.
By leveraging their existing HTTPS infrastructure, these companies effectively:

• Centralized DNS resolution,
• Captured DNS analytics and user data,
• Shifted trust from ISPs to large global web platforms.

DoH’s deep integration into browsers (Firefox, Chrome, Edge) defaults users toward a few big resolvers—consolidating control of global DNS traffic into the hands of a few corporations.

This is not privacy; it is recentralization under different owners.

DNSCrypt, in contrast, was explicitly designed to be:

• Distributed — anyone can run a resolver,
• Independent — no corporate gatekeepers,
• Lightweight — minimal hardware requirements,
• Always secure — no fallback to plaintext.

✅ Result:
DNSCrypt keeps DNS decentralized and democratized, as the Internet was meant to be.

---

6. Blocking and Censorship Resistance

Protocol	Port	Blocking Difficulty	SNI Exposure	Description
DoT	853	❌ Trivial to block	None	Easily identified by fixed port
DoH	443	⚠️ Moderate	Yes	Can be blocked via SNI or TLS fingerprinting
DNSCrypt	Flexible (UDP/TCP, often 443)	✅ Hard to block	None	No SNI, no fixed port, no HTTP fingerprint

6.1 DoT: Obvious Target

DoT’s dedicated port (853) makes it trivial for firewalls or ISPs to block.
Some countries already do this at the national level.

6.2 DoH: Not as Resistant as Claimed

DoH’s use of HTTPS initially appeared censorship-resistant, but in practice:

• SNI (Server Name Indication) reveals the DoH hostname.
• TLS fingerprinting identifies DoH traffic patterns.
• Many national and enterprise firewalls already block common DoH endpoints (Cloudflare, Google, Quad9, etc.).

6.3 DNSCrypt: Stealth and Flexibility

DNSCrypt avoids these issues:

• It has no SNI, no HTTP signature, and no fixed port.
• It can run on UDP or TCP, including port 443, blending with normal traffic.
• It supports anonymized relays, hiding the actual resolver from observers.

✅ Result:
DNSCrypt provides genuine censorship resistance, not just “security by camouflage.”

---

7. Performance and Real-World Latency

7.1 UDP Advantages

DNSCrypt’s UDP-based design delivers:

• Zero-RTT operation (no handshake delay),
• Native parallelism (multiple queries in flight),
• Lightweight retransmission (without TCP timeouts),
• Low CPU/memory footprint (ideal for routers and embedded devices).

7.2 Real-World Data from dnscrypt-proxy

The open-source dnscrypt-proxy tool automatically benchmarks all configured resolvers (DNSCrypt, DoT, and DoH) in real time.

Empirical results across thousands of installations consistently show:

• DNSCrypt resolvers have lower average latency than equivalent DoH resolvers.
• Even when DoH uses HTTP/3 (QUIC), DNSCrypt remains faster in nearly all conditions.
• The difference is most pronounced on high-latency or lossy links, where UDP’s connectionless nature outperforms QUIC’s congestion control overhead.

Protocol	Average Latency	Connection Overhead	Parallelism	Transport	Relative Performance
DNSCrypt	Lowest	None (UDP)	Native	UDP/TCP	⚡
DoT	Moderate	1-RTT (TLS)	Limited	TCP	⚙️
DoH (HTTP/3)	Highest	1–2-RTT (QUIC)	HTTP multiplexed	QUIC	🐢

✅ Result:
In the real world, DNSCrypt outperforms both DoT and DoH—including over QUIC.

---

8. Summary Comparison

Feature	DNSCrypt	DoT	DoH
Standardization	IETF Draft (2025)	RFC 7858	RFC 8484
Bootstrap Required	❌ No	✅ Yes	✅ Yes
Transport	UDP/TCP	TCP	HTTP/TLS/QUIC
PKI Dependency	❌ None	✅ Yes	✅ Yes
Blocking Resistance	✅ Strong	❌ Weak	⚠️ Moderate
Authenticity	✅ Signed keys	⚠️ CA validation	⚠️ CA validation
Extensibility	✅ Modular	❌ Rigid	⚠️ Limited
Parallelism	✅ Native	❌ Serial	⚠️ HTTP-layer
Centralization Risk	❌ Low	⚙️ Medium	🔥 High (CDNs)
Real-World Latency	⚡ Lowest	⚙️ Medium	🐢 Highest

---

9. Conclusion

Despite the IETF’s later standardization of DoT and DoH, DNSCrypt remains the most technically robust encrypted DNS protocol.

It offers:

• Encryption and authenticity from the first packet,
• Lower latency and simpler transport,
• Freedom from the TLS/CA ecosystem,
• True decentralization and resistance to corporate control,
• Real privacy and real-world efficiency.

DoT is rigid and easily blocked.
DoH is bloated, centralized, and falsely marketed as censorship-resistant.
DNSCrypt, by contrast, is lean and open.

[mflsim]

As I know dnscrypt doesn't have obfuscate traffic option. So it's trivial to block by any modern DPI by patterns. DoH more resistant to blocking because looks like usual https traffic