Frequently Asked Questions

What is DNSCrypt?

DNSCrypt is a protocol that authenticates 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.

DNS

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.

DNSSEC

Why use DNSCrypt?

  • Encrypts and authenticates the DNS traffic
  • Specifically designed for DNS
  • Has been battle tested since 2011
  • A good amount of servers support the protocol
  • Includes mitigations against DNS amplification attacks
  • Can use UDP and TCP for transport
  • Inherently supports reordering, parallelism and priorities
  • Keeps a minimal number of states server-side
  • Very simple to implement; requires only two standard cryptographic constructions
  • Doesn’t require a TLS stack, which vastly reduces the attack surface
  • Doesn’t have any insecure parameters
  • Doesn’t rely on X509 certificates and Certificate Authorities
  • Cannot be MITM’d by standard tools
  • Enforces certificate signatures
  • Has a complete specification since 2013
  • Regular DNS and DNSCrypt can share the same port (although port 443 is recommended due to routers frequently hijacking port 53)
  • DNSCrypt and DoH can also be served simultaneously on the same port
  • Can hide client IP addresses from servers (Anonymized DNSCrypt)
  • A prototype using post-quantum cryptography is available
  • The RFC is still a work in progress
DNSCrypt with DNSSEC

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]

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

DNS over TLS (RFC7858)

  • Full encryption of the DNS protocol
  • Has a low, but increasing number of servers in deployment
  • Partially specified as a RFC
  • Many implementations completed at various stages
  • Provides more information than regular DNS to resolver operators in order to fingerprint clients, and this has (intentionally?) never been addressed in the specification
  • Uses a dedicated port (853) likely to be blocked or monitored in situations where DNS encryption is useful
  • Initial connection is slow due to the long handshake (until TLS 1.3 is deployed, which can take time due to middleboxes)
  • Not well understood even by its proponents. It is a truck, as it is heavy and slow to load, but most if not all implementations perform a full round trip for every packet (even the excellent miekg/dns library as used by Tenta).
  • Padding rules haven’t been specified besides a draft that doesn’t have any implementations, and a last-minute hack that requires altering DNS record sets before wrapping them
  • Requires a full TLS stack, introducing a large attack surface
  • Difficult to implement securely. Validating TLS certificates in non-browser software is the most dangerous code in the world
  • Readily compatible with industry-standard TLS interception/monitoring devices. Having people install additional root certificates is easier than custom software. Vendors are always ready to passively extract information from TLS 1.3 sessions.
  • Requires TCP
  • Requires sessions tracking on the server
  • TLS is a generic transport mechanism. It doesn’t support reordering and parallelism and doesn’t include any ways to manage priorities. New mechanisms need to be invented and implemented to do so.
  • Key management can be surprisingly hard especially if public key pinning is used by clients
  • Allows insecure algorithms and parameters
  • Will be difficult to improve without introducing more hacks. Unlikely to benefit from any improvements besides new TLS versions or homegrown reinventions.
  • Questionable practical benefits over DoH

DNS over HTTPS (DoH)

  • Full encryption of the DNS protocol
  • New implementations are being developed
  • The minimum version of HTTP used by DoH should be HTTP/2
  • Uses standard HTTP/2 or HTTP/3, on the standard port (443)
  • Will automatically benefit from improvements made to HTTP
  • Less likely to be blocked than other options
  • Can be trivially deployed on any web server, and run along existing websites; DNS response are served like simple web pages
  • Can share the same infrastructure as existing websites, and share the same certificates
  • Simple to implement over any existing web stack
  • Immediately compatible with caching proxies and CDNs
  • Allows web browsers to perform DNS queries using Javascript
  • Supports reordering, parallelism and priorities, thanks to HTTP/2
  • Can leverage existing padding mechanisms (HTTP/2 frames padding)
  • Implemented by Google DNS
  • Supported by CuRL: will soon be available in all programming languages with bindings for libcurl
  • Available in Firefox
  • Specified as a RFC
  • Can be accessed via relays (ODoH, DooH), even though this leaks more information that expected
  • Provides more information than regular DNS to resolver operators in order to fingerprint clients, but this is being addressed in the specification
  • Requires a full TLS stack and a web server
  • Interception/monitoring tools are readily available
  • Key management can be surprisingly hard especially if public key pinning is used by clients
  • Allows insecure algorithms and parameters
  • Requires TCP
  • Rarely deployed in a way that would prevent it to be trivially blocked without ECH

DNS-over-DTLS (RFC8094)

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

[DNS over QUIC] (RFC9250)

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

Practical considerations

All the solutions above offer the same practical security level. Compatibility with existing tools and infrastructure is what makes an actual difference.