Frequently Asked Questions

What is DNSCrypt?

DNSCrypt is a protocol that encrypts, authenticates and optionally anonymizes communications between a DNS client and a DNS resolver. It prevents DNS spoofing. It uses cryptographic signatures to verify that responses originate from the chosen DNS resolver and haven’t been tampered with.

It is an open specification, with free and open source reference implementations, and it is not affiliated with any company or organization.

What is DNS?

DNS is a globally distributed database that maps names to values. It is constantly used by all applications communicating over the Internet and private networks.

It typically translates names such as www.google.com into IP addresses such as 216.58.199.36, so that devices can determine the path to follow in order to communicate with each other.

So what is the problem?

Originally, the DNS protocol didn’t include any encryption nor authentication mechanisms; any device between a client and a DNS server could monitor and interfere with DNS traffic, without this being detected by the client.

Attackers on a local network can abuse this to conduct trivial attacks. More recently, malicious DNS servers have been massively used by malware.

The DNS security extensions (DNSSEC) were designed to partially mitigate this design flaw, by adding digital signatures to DNS responses.

What is DNSSEC

DNSSEC is a DNS Extension that allows a client to validate the DNS response on supported domains and TLDs.

Resolvers check the digital signature of DNS responses to verify that the data match what the zone owner initially configured.

Unfortunately, DNSSEC has received limited adoption, remains incompatible with some devices and software pieces, and doesn’t prevent the traffic from being monitored.

Why use DNSCrypt?

Security

• thumb_up No insecure bootstrap: encryption starts from the very first packet, unlike DoT/DoH which require resolving a hostname first
• thumb_up Doesn’t rely on X509 certificates and Certificate Authorities; uses static public keys verified through cryptographic signatures
• thumb_up Resistant to CA compromise and state-level coercion
• thumb_up Cannot be MITM’d by standard TLS interception tools
• thumb_up Doesn’t require a TLS stack, which vastly reduces the attack surface
• thumb_up Doesn’t have any insecure parameters or algorithms
• thumb_up Includes mitigations against DNS amplification attacks
• thumb_up Can hide client IP addresses from servers (Anonymized DNSCrypt)

Performance

• thumb_up Zero-RTT operation: no handshake delay
• thumb_up Native parallelism: multiple queries in flight simultaneously
• thumb_up Lower latency than DoH, even when DoH uses HTTP/3
• thumb_up Can use UDP and TCP for transport
• thumb_up Inherently supports reordering, parallelism and priorities
• thumb_up Keeps a minimal number of states server-side

Decentralization and censorship resistance

• thumb_up Designed to be distributed: anyone can run a resolver without corporate gatekeepers
• thumb_up No SNI, no HTTP signature, no fixed port—harder to block and fingerprint
• thumb_up Supports anonymized DNS relays for additional privacy
• thumb_up Regular DNS and DNSCrypt can share the same port (port 443 is recommended due to routers frequently hijacking port 53)
• thumb_up DNSCrypt and DoH can also be served simultaneously on the same port

Protocol design

• thumb_up Specifically designed for DNS, not a generic transport layer
• thumb_up Very simple to implement; requires only two standard cryptographic constructions
• thumb_up Built-in query padding
• thumb_up Multiple crypto suites (including X25519, Ed25519)
• thumb_up Extensible without requiring cross-layer redesigns
• thumb_up A prototype using post-quantum cryptography is available
• thumb_up Has a complete specification since 2013
• thumb_up Battle tested since 2011
• thumb_down The RFC is still a work in progress

How do I get started with using DNSCrypt?

See Client Implementations

How do I get started with running my own DNSCrypt server?

See Server Implementations

Other protocols

[DNS over SSH]

• thumb_up Full encryption of the DNS protocol
• thumb_up Can be deployed on any system already running an SSH server
• thumb_up Battle-tested, widely implemented transport protocol
• thumb_up Doesn’t depend on root CAs
• thumb_up Can use DNSSEC or private CAs for public key verification
• thumb_up Supports multiple authentication mechanisms
• thumb_up Doesn’t require a TLS stack; modern implementations do not even require OpenSSL any more
• thumb_down Very tricky to configure securely
• thumb_down Requires TCP
• thumb_down Current implementations don’t scale well server-side
• thumb_down UDP queries require TCP encapsulation
• thumb_down The SFTP protocol supports reordering and parallelism, but common DNS-over-SSH tunelling cannot use this

DNS over TLS (RFC7858)

• thumb_up Full encryption of the DNS protocol
• thumb_up Specified as an RFC
• thumb_up Many implementations available
• thumb_down Insecure bootstrap: requires resolving the resolver’s hostname through plaintext DNS before encryption can begin
• thumb_down Relies on the global TLS PKI system, vulnerable to CA compromises and state-level coercion
• thumb_down Uses a dedicated port (853) that is trivially blocked in situations where DNS encryption is most needed
• thumb_down Requires a full TLS stack, introducing a large attack surface
• thumb_down Readily compatible with industry-standard TLS interception/monitoring devices
• thumb_down Difficult to implement securely. Validating TLS certificates in non-browser software is the most dangerous code in the world
• thumb_down Initial connection is slow due to the TLS handshake
• thumb_down Requires TCP; no UDP support
• thumb_down TLS is a generic transport mechanism that doesn’t support reordering and parallelism or priorities
• thumb_down Allows insecure algorithms and parameters
• thumb_down Padding rules not well specified
• thumb_down Questionable practical benefits over DoH

DNS over HTTPS (DoH)

• thumb_up Full encryption of the DNS protocol
• thumb_up Uses standard HTTP/2 or HTTP/3, on the standard port (443)
• thumb_up Less likely to be blocked than DoT
• thumb_up Can be deployed on any web server alongside existing websites
• thumb_up Immediately compatible with caching proxies and CDNs
• thumb_up Specified as an RFC
• thumb_up Widely supported in browsers
• thumb_down Insecure bootstrap: requires resolving the resolver’s hostname through plaintext DNS before encryption can begin
• thumb_down Relies on the global TLS PKI system, vulnerable to CA compromises and state-level coercion
• thumb_down Has centralized DNS resolution among major CDN providers (Cloudflare, Google), capturing DNS analytics
• thumb_down Higher latency than DNSCrypt, even when using HTTP/3
• thumb_down Requires a full TLS stack and a web server, introducing a large attack surface
• thumb_down TLS interception/monitoring tools are readily available
• thumb_down SNI exposes the resolver hostname, making traffic easily identifiable and blockable
• thumb_down Provides more information than regular DNS to resolver operators for client fingerprinting
• thumb_down Allows insecure algorithms and parameters
• thumb_down Requires TCP
• thumb_down Relay protocols (ODoH) leak more information than expected

DNS-over-DTLS (RFC8094)

• thumb_down No known implementations
• thumb_down Many security vulnerabilities in OpenSSL due to DTLS

[DNS over QUIC] (RFC9250)

• thumb_up Full encryption of the DNS protocol
• thumb_down Uses a dedicated port: 853, can’t use port 53
• thumb_down Client devices and IP addresses can be linked
• thumb_down No clear advantage over HTTP/3

Practical considerations

DNSCrypt offers security advantages that DoT and DoH cannot match: no insecure bootstrap, no CA dependency, and resistance to traffic analysis. Combined with its lower latency and decentralized design, DNSCrypt remains the strongest choice for DNS security and privacy.