Plain DNS is the last major internet protocol that most people still send in the clear. Every time your device resolves a hostname, that query travels unencrypted to your resolver, and anyone on the path can read it, log it, or forge a reply. The forged reply problem is the dangerous one: without authentication, your resolver has no way to prove that the answer it received actually came from the server it asked, which is the whole basis of cache poisoning attacks.
DNSCrypt was one of the first practical answers to this. It was created by Frank Denis around 2011, originally associated with OpenDNS, and it set out to do two things at once: encrypt DNS traffic so it cannot be read on the wire, and authenticate it so a client can be certain a response came untampered from the resolver it chose. The current version, DNSCrypt v2, is what people run today, usually through the dnscrypt-proxy client.
Authentication without the web CA system
This is the design decision that sets DNSCrypt apart. DNS over HTTPS and DNS over TLS both authenticate the resolver using the same public certificate authority system that secures websites. That works, but it inherits every weakness of that system: a misissued certificate from any trusted CA can impersonate your resolver, and the trust chain runs through hundreds of organizations you never chose.
DNSCrypt takes a different path. Each resolver has a long-term public key. You configure your client with that key, or with a "stamp" that encodes it, and the client pins it. The resolver then serves short-lived certificates signed by that long-term key, each certificate carrying a temporary encryption key. Your client verifies the certificate's signature against the pinned long-term key before it trusts anything. There is no certificate authority in the loop, because the trust anchor is the specific key of the specific resolver you deliberately chose to use.
With DoH or DoT, you trust that the entire CA ecosystem behaves. With DNSCrypt, you trust exactly one key belonging to exactly one resolver you picked. That is a smaller and more legible trust surface. The trade is that you have to obtain that key correctly in the first place, which the stamp format and curated resolver lists handle in practice.
The cryptography underneath
DNSCrypt is built on well-understood primitives rather than a bespoke scheme. Key exchange uses X25519, the Curve25519 Diffie-Hellman function. Encryption and authentication use either XSalsa20-Poly1305 or XChaCha20-Poly1305, the same authenticated encryption constructions that libsodium popularized. These are the same building blocks used across a large swath of modern secure software, which means DNSCrypt did not have to invent new cryptography and did not carry the risk that comes with inventing it.
The short-lived certificates give the system a rotation property. Because the temporary encryption keys expire and get replaced, a resolver operator can rotate them regularly, limiting how much traffic a single compromised key could ever expose. The long-term key, the one you pinned, stays stable so you keep a fixed anchor to verify against.
Anonymized DNSCrypt and the metadata problem
Encrypting DNS solves the on-path eavesdropper, but it does not solve the resolver itself. Whoever runs your encrypted resolver still sees every query tied to your IP address. For many people the resolver operator is exactly who they were trying to keep their browsing away from. Encryption to that operator does nothing about that.
Anonymized DNSCrypt addresses this by inserting a relay between you and the resolver. Your client encrypts the query so that only the destination resolver can read it, then sends it through a relay. The relay sees your IP address but not the contents of your query. The resolver sees the query contents but, because the traffic arrived through the relay, not your IP address. No single party holds both halves.
The relay knows who you are but not what you asked. The resolver knows what you asked but not who you are. Separating those two facts is the entire point. The design principle behind anonymized DNS
If this sounds familiar, it is the same separation principle behind Oblivious DNS over HTTPS, which brought the idea into the DoH world later. DNSCrypt got there first with its relay mode. Neither is as strong as a full mix network, and both depend on the relay and resolver not colluding, but both meaningfully raise the cost of tying a person to their query stream.
DNSCrypt next to DoH and DoT
| Property | DNSCrypt | DoH / DoT |
|---|---|---|
| Encrypts queries | Yes | Yes |
| Resolver authentication | Pinned resolver key | Web CA system |
| Built-in relay mode | Yes (anonymized) | Only via ODoH |
| Blends with web traffic | No | DoH: Yes |
| IETF standard | No, community spec | Yes (RFC 8484 / 7858) |
The one column where DoH clearly wins is traffic blending. DNS over HTTPS looks like ordinary HTTPS on port 443, so a network operator cannot easily single it out and block it. DNSCrypt uses its own ports and is trivially identifiable, which means a restrictive network can drop it. If your concern is a censor who blocks encrypted DNS, DoH is harder to stop. If your concern is a cleaner trust model and built-in query anonymization, DNSCrypt has real advantages. For the broader landscape, our comparison of encrypted DNS options lays out the full set of trade-offs.
What encrypted DNS does not do
It is worth being clear about the limits, because encrypted DNS is often oversold. Encrypting your DNS queries hides which hostnames you look up from your ISP and from anyone on the local network. It does not hide the destination IP address your connection then goes to, and it does not hide the server name your browser sends in the TLS handshake unless Encrypted Client Hello is also in play. A network observer who loses your DNS queries can often still infer where you went by watching the connections that follow.
DNSCrypt is also not authentication of the DNS data itself in the way DNSSEC is. DNSCrypt secures the channel between you and your resolver. DNSSEC secures the records from the authoritative source down the chain, so it protects against a lying resolver. They solve different problems and compose well together: DNSCrypt for the last-mile channel, DNSSEC for end-to-end record integrity.
Where this fits in a privacy stack
DNS is one layer in a much larger picture, and no single tool at that layer makes you private on its own. Encrypted DNS keeps your lookups off the local wire and out of your ISP's logs, which closes one specific and very real exposure. It does not substitute for encrypting the content of what you actually send, which is a separate layer entirely and the one that matters most once a connection is established.
At Haven we work several layers up from DNS, on the messages themselves, where end-to-end encryption means the content is unreadable regardless of what any resolver or network operator sees. The two concerns reinforce each other rather than compete. Reducing metadata leakage at the network layer and encrypting content at the application layer are both part of the same posture, and DNSCrypt remains one of the sharper tools for the network-layer half of that job.