DNSCrypt
DNSCrypt is a lightweight, open protocol that encrypts, authenticates, and optionally anonymizes Domain Name System (DNS) communications between clients and resolvers, using cryptographic signatures to verify the origin and integrity of responses while preventing DNS spoofing attacks.[1]Introduced in 2011 as a response to vulnerabilities in unencrypted DNS traffic, such as eavesdropping and man-in-the-middle tampering, it pioneered practical DNS encryption independent of broader standardization efforts.[2]
Version 2, specified and deployed around 2013, enhanced security with support for UDP and TCP over port 443—commonly used for HTTPS to evade filtering—and compatibility with DNSSEC for additional validation.[3]
In 2019, anonymized DNSCrypt extended the protocol to obscure client IP addresses via proxy relays, further bolstering privacy without relying on centralized infrastructure.[1]
Developed primarily by Frank Denis under the pseudonym jedisct1, with early contributions from Yecheng Fu, DNSCrypt remains unaffiliated with any corporation and powers open-source implementations like dnscrypt-proxy, which has facilitated its adoption in diverse operating systems and routers despite competition from protocols like DNS over HTTPS.[4][5]
As the most widely deployed encrypted DNS solution to date, it emphasizes performance, minimal overhead, and resistance to amplification attacks through authenticated, short-lived query-response exchanges.[1]
History
Origins and Initial Development
DNSCrypt originated as a protocol to secure Domain Name System (DNS) traffic against spoofing and man-in-the-middle attacks by encrypting and authenticating communications between clients and resolvers. It was principally designed by Frank Denis, known online as jedisct1, in collaboration with Yecheng Fu, with the aim of providing a lightweight, high-performance alternative to unencrypted DNS queries that were vulnerable to interception and tampering.[6][5] The initial development traces back to 2008, when early implementations emerged on BSD Unix platforms, influenced by OpenBSD's experimental secure DNS tunneling mechanisms intended to mitigate spoofing risks rather than primarily enhance privacy. These prototypes focused on authenticating DNS responses using public-key cryptography without requiring widespread infrastructure changes, addressing the era's prevalent threats like cache poisoning demonstrated in attacks such as the 2008 Kaminsky vulnerability.[7][1] By late 2011, the protocol had matured sufficiently for public deployment, with OpenDNS launching the first commercial DNS service supporting DNSCrypt on December 6, 2011, enabling users to opt into encrypted resolutions via compatible clients like the open-source dnscrypt-proxy software developed by Denis. This marked the transition from experimental roots to practical adoption, emphasizing resolver authentication through short-lived keys and ephemeral public keys to balance security and efficiency.[8][1]Release of Version 2 and Key Enhancements
DNSCrypt version 2 of the protocol was specified and implemented in 2013, marking a significant evolution from the initial version released in 2011. This update addressed limitations in the original design, particularly around encryption robustness and operational efficiency, while maintaining the core goal of encrypting and authenticating DNS queries over UDP to prevent eavesdropping, tampering, and spoofing. The protocol's reference implementation in tools like dnscrypt-proxy facilitated broader adoption, with version 2 becoming one of the most deployed encrypted DNS solutions by enabling simpler server discovery and client configuration mechanisms.[1] A primary enhancement in version 2 was the shift to the XChaCha20-Poly1305 authenticated encryption scheme, replacing the XSalsa20-Poly1305 used in version 1. This change provided greater nonce misuse resistance, reducing risks from improper nonce handling in high-volume DNS traffic, and incorporated a 192-bit nonce for enhanced security without relying on TCP fallbacks for amplification mitigation. Additionally, version 2 introduced short-lived server certificates, typically valid for no more than 24 hours, to enforce automated key rotation and improve forward secrecy, thereby minimizing long-term exposure from static keys or expired credentials that plagued earlier deployments.[9][3] Version 2 also resolved DNS amplification vulnerabilities inherent in version 1 by structuring packets to limit response sizes relative to queries, allowing pure UDP operation without mandatory TCP escalation. It formalized "DNS stamps"—compact, self-contained descriptors for resolvers including public keys, endpoints, and protocols—which streamlined client setup and verification, reducing configuration errors and enabling load balancing across multiple resolvers for resilience against failures or censorship. These features collectively enhanced scalability and privacy, with clients able to generate ephemeral session keys per query for added protection, though at higher computational cost.[3][9]Recent Standardization Efforts
In 2023, contributors including representatives from Cisco initiated efforts to formalize the DNSCrypt protocol through an Internet Engineering Task Force (IETF) Request for Comments (RFC), aiming to enhance interoperability and define protocol version 3 with upgrades such as P-224 or P-256 elliptic curve digital signatures for session authentication and AES-GCM for encryption.[10] These plans addressed limitations in earlier versions while preserving core protections against eavesdropping, spoofing, and man-in-the-middle attacks on client-resolver traffic.[10] The primary recent development is the individual IETF Internet-Draft "The DNSCrypt Protocol" (draft-denis-dprive-dnscrypt), authored by Frank Denis, with version 07 published on October 5, 2025.[5] This draft specifies the protocol's mechanics, including initial certificate exchange for resolver authentication, encrypted query and response packet structures (using client/resolver magic bytes, nonces, and X25519-based encryption), and compatibility with UDP/TCP transports on port 443.[5] Intended as an informational document rather than a standards-track RFC, it remains in active development without adoption by an IETF working group as of late 2025, with an expiration date of April 8, 2026.[5] Supporting resources include a GitHub-hosted formal specification mirroring the draft's details, emphasizing open-source implementations for clients and servers.[11] Despite these advances, DNSCrypt's lack of full IETF standardization has limited its integration compared to protocols like DNS over TLS, though the draft provides a basis for potential future RFC progression.[5]Technical Overview
Core Principles and Objectives
DNSCrypt aims to mitigate the inherent vulnerabilities of the standard DNS protocol, which transmits queries and responses in plaintext, exposing them to eavesdropping, interception, modification, and spoofing by attackers on the network path. By encrypting DNS traffic and authenticating both queries and responses using public-key cryptography, the protocol ensures confidentiality, integrity, and authenticity, allowing clients to verify that responses come unaltered from the designated resolver.[1][11] This addresses core DNS weaknesses, such as the absence of built-in encryption, which facilitates man-in-the-middle attacks and surveillance, as demonstrated in real-world incidents like widespread ISP-level DNS hijacking reported since the early 2010s.[12] A foundational principle is the use of short-lived, ephemeral session keys derived via key exchange mechanisms like X25519 for forward secrecy, preventing decryption of past sessions even if long-term keys are compromised. Authentication relies on resolver-provided public keys or certificates, enabling clients to establish trust without depending on centralized certificate authorities or complex public-key infrastructure. The protocol prioritizes lightweight operation over UDP, avoiding the overhead of TCP/TLS handshakes, to maintain performance comparable to unencrypted DNS while resisting denial-of-service attacks through padded, authenticated payloads.[11][5] Objectives extend to optional anonymity via the Anonymized DNSCrypt extension, introduced in 2019, which routes queries through proxy relays to hide client IP addresses from resolvers, thereby reducing metadata leakage without compromising query integrity. This design reflects a commitment to user privacy in environments where resolvers might log or share query data, while promoting an open ecosystem through freely available resolver stamps—compact descriptors of server capabilities and keys—for easy client configuration and discovery. Overall, DNSCrypt seeks broad deployability by supporting diverse implementations and emphasizing resistance to traffic analysis, with no reliance on higher-layer protocols like HTTPS.[1][13]Key Components and Architecture
DNSCrypt operates through a proxy-based architecture comprising a client-side proxy and a server-side proxy, which together encrypt and authenticate DNS queries and responses between end-user devices and upstream resolvers. The client proxy, such as dnscrypt-proxy, intercepts unencrypted DNS traffic from local applications or operating systems, encapsulates it within the DNSCrypt protocol, and transmits it over UDP or TCP (typically port 443) to the server proxy. The server proxy, often implemented via tools like dnscrypt-wrapper, decrypts incoming queries, forwards them to a trusted recursive or authoritative DNS resolver (e.g., Unbound or PowerDNS), encrypts the resulting responses, and returns them to the client proxy for decryption and delivery to the originating client.[14][15] This layered approach ensures compatibility with existing DNS infrastructure while adding security without requiring modifications to DNS servers or clients.[3] At the protocol level, DNSCrypt version 2 relies on asymmetric and symmetric cryptography for session establishment and data protection. Key exchange uses the X25519 elliptic curve to derive ephemeral shared secrets from the resolver's public key (included in a signed certificate) and the client's secret key, enabling forward secrecy. Authenticated encryption employs XChaCha20-Poly1305, which provides confidentiality, integrity, and resistance to replay attacks via a 24-byte nonce and 16-byte message authentication code (MAC). Certificates are signed with Ed25519 for server authentication, fetched initially via an unencrypted DNS query or pre-shared DNS stamps containing the provider's public key, serial numbers, and endpoints.[3][15] Sessions remain stateless, supporting out-of-order responses and asynchronous queries without persistent connections.[15] Message formats enforce structure to prevent tampering and ensure parsing. A client query begins with an 8-byte client magic string, followed by the 32-byte client public key, a client-generated nonce, and the XChaCha20-Poly1305-encrypted DNS query (padded to multiples of 64 bytes, minimum 256 bytes for UDP to mitigate amplification attacks). The server response includes an 8-byte resolver magic string (fixed as 0x72 0x36 0x66 0x6e 0x76 0x57 0x6a 0x38), a nonce derived from the query nonce, and the encrypted DNS response.[3][15] This design accommodates multiple concurrent queries per session and supports variants like anonymized DNSCrypt for added privacy through proxy chaining, though core architecture centers on direct client-server exchanges.[3]Protocol Specifications
Encryption and Authentication Mechanisms
DNSCrypt version 2 employs authenticated encryption with associated data (AEAD) to secure DNS queries and responses, using XChaCha20-Poly1305 as the primary cryptographic primitive.[3][16] This combination provides both confidentiality through the XChaCha20 stream cipher and integrity/authenticity via the Poly1305 message authentication code (MAC), with a 16-byte MAC prepended to the ciphertext.[3] The protocol requires a 24-byte nonce for each message to mitigate replay attacks, consisting of client-chosen bytes padded with nulls in queries and a full nonce in responses.[3] Key exchange occurs via X25519 (based on Curve25519 elliptic curve Diffie-Hellman), where the client generates an ephemeral secret key and derives a shared secret using the resolver's long-term public key.[3][16] This shared secret, combined with the nonce and message data, feeds into XChaCha20 for encryption, extending ChaCha20 with a 192-bit nonce for non-interactive key derivation without requiring synchronized counters.[3] Resolver certificates, which include the public key and supported encryption systems, are signed with Ed25519 (producing a 64-byte signature) to enable client verification against a provider's root key, ensuring the resolver's authenticity before session establishment.[3][16] Query messages begin with an 8-byte client magic string, followed by the client's ephemeral public key (32 bytes), a partial nonce (12 client bytes + 12 nulls), and the encrypted DNS query payload.[3] Responses mirror this structure with an 8-byte resolver magic, a full 24-byte nonce (incorporating the client's nonce), and the encrypted DNS response, authenticated via the Poly1305 MAC to detect tampering or spoofing.[3][16] These mechanisms collectively prevent man-in-the-middle attacks, eavesdropping, and DNS spoofing by binding encryption keys to authenticated identities and enforcing fresh nonces per transaction.[3]Anonymized DNSCrypt Variant
Anonymized DNSCrypt extends the core DNSCrypt protocol by incorporating relay servers to conceal client IP addresses from DNS resolvers, thereby preventing servers from linking queries to specific users. Introduced in October 2019, this variant addresses a limitation of standard DNSCrypt, where encryption protects query content but exposes client IPs to resolvers, potentially enabling traffic analysis or correlation attacks.[1][17] The protocol operates by having clients send specially formatted queries to a configured relay, which forwards them to the target resolver without decrypting the content. Client queries prepend a fixed 10-byte anonymization magic sequence (0xff repeated eight times followed by two 0x00 bytes) to the standard DNSCrypt query, along with the resolver's IPv6 address (padded to 16 bytes) and port (2 bytes in big-endian format). This structure allows the relay to identify anonymized traffic, validate the target (ensuring non-private IPs and typically port 443), and forward the encrypted payload via UDP to the resolver. The resolver processes the query as a conventional DNSCrypt request, unaware of the originating client IP, and returns the response through the same relay path. Encryption relies on DNSCrypt's XChaCha20-Poly1305 authenticated encryption, ensuring confidentiality and integrity throughout.[17][11]
Relay servers enforce strict validation: they reject malformed queries, oversized responses (which must be smaller than the original query), or those failing DNSCrypt format checks, forwarding only valid responses unmodified to mitigate amplification attacks. Clients must configure both relays and resolvers, often selecting from public lists to distribute load and enhance resilience against single-point failures or censorship. This setup supports both UDP and TCP transports, preserving DNSCrypt's authentication via public-key cryptography and ephemeral session keys.[17]
Operational guidelines recommend separating relay and resolver roles to avoid centralized trust, with relays implementing rate limiting and abuse monitoring to prevent misuse, such as DDoS reflection. While this variant improves privacy over DNS over HTTPS (DoH) by obscuring client identities without relying on centralized proxies, it introduces relay dependency, potentially increasing latency and requiring careful selection of trustworthy relays to avoid new correlation risks. Implementations like dnscrypt-proxy integrate this via configuration sections specifying relay chains for multi-hop anonymization.[17][1]
Resolver Authentication and Key Management
In DNSCrypt version 2, resolver authentication relies on certificates signed using the provider's long-term Ed25519 public key, which clients obtain out-of-band through mechanisms such as DNS stamps or curated resolver lists.[3][17] Clients initiate authentication by sending an unencrypted TXT query to a subdomain like2.dnscrypt-cert.<resolver-domain>, prompting the resolver to respond with one or more certificates containing its short-term resolver public key.[3][17] Each certificate includes a fixed 8-byte client magic string, a serial number for versioning, start and end timestamps defining a validity period (typically up to 7 days), a protocol version byte specifying the encryption system (e.g., 0x02 for X25519-XChaCha20-Poly1305), and a 64-byte Ed25519 signature over the preceding fields.[3] Clients select the certificate with the highest serial number among those valid at the current time and verify its signature against the provider public key; invalid or expired certificates are discarded, and clients recheck for updates at least hourly.[3][17]
Key management emphasizes ephemeral and rotating keys to limit exposure. Resolvers generate short-term X25519 key pairs for encryption, with the public portion (32 bytes) embedded in certificates; these pairs must rotate at least every 24 hours, and previous secret keys must be securely erased post-rotation.[17] During transitions, resolvers support both old and new keys for a grace period of up to 4 hours to accommodate client certificate caching.[3] The provider's Ed25519 secret key, used for signing certificates, should be protected in hardware security modules to prevent compromise.[17] Clients generate their own ephemeral X25519 key pairs per query or session, including the public key in the query preamble alongside a 12-byte client nonce; the resolver derives a shared secret via X25519 key exchange, combines it with a resolver-chosen 12-byte nonce for a 24-byte session nonce, and uses the resulting XChaCha20-Poly1305 authenticated encryption to protect DNS payloads.[3][17] This process ensures response authentication, as clients recompute the shared secret and verify the Poly1305 tag using the resolver's authenticated public key from the certificate.[3] Nonces must remain unique per session to prevent replay attacks, with resolvers rejecting duplicates.[17]
Comparisons to Alternative Protocols
DNSCrypt versus DNS over TLS (DoT)
DNSCrypt and DNS over TLS (DoT) both aim to secure DNS communications by encrypting queries and responses to prevent eavesdropping, spoofing, and tampering, but they employ distinct cryptographic and transport mechanisms. DNSCrypt, introduced in 2011, uses a lightweight, custom protocol that wraps DNS payloads in authenticated encryption without relying on the TLS stack, supporting both UDP and TCP transports typically on port 443.[3] In contrast, DoT, standardized in RFC 7858 in May 2016, tunnels DNS over TLS-encrypted TCP connections on dedicated port 853, leveraging established TLS infrastructure for server authentication via X.509 certificates.[18] While both protocols provide confidentiality and integrity, DNSCrypt emphasizes minimal overhead and resistance to protocol-specific vulnerabilities inherent in TLS, whereas DoT benefits from broader interoperability due to its reliance on standardized TLS handshakes.[19] A primary difference lies in authentication and key management. DNSCrypt authenticates resolvers using pre-published public keys embedded in "stamps" or descriptors, enabling clients to verify server identity without a public key infrastructure (PKI) or certificate authorities, thus avoiding risks from CA compromises or certificate misissuance.[3] DoT, however, mandates TLS certificate validation, which introduces dependencies on trusted root CAs and exposes systems to the broader TLS attack surface, including vulnerabilities in certificate parsing or chain validation.[18] [19] DNSCrypt employs ephemeral key exchanges (e.g., via X25519) and symmetric ciphers like XChaCha20-Poly1305 for session encryption, generating short-lived keys per query to limit exposure. DoT inherits TLS cipher suites, which, while flexible, can include configurable parameters potentially leading to weaker configurations if not strictly enforced.[3] Transport and performance characteristics diverge notably. DNSCrypt's UDP support facilitates lower latency and compatibility with stateless DNS operations, mitigating issues like TCP head-of-line blocking and enabling features such as query reordering and parallelism without full connection reestablishment.[19] DoT requires TCP, incurring overhead from initial TLS handshakes (typically 1-2 round trips) and retransmissions on packet loss, though it provides reliable stream encryption.[18] [19] Port usage further differentiates them: DNSCrypt's default port 443 blends with HTTPS traffic, potentially evading simplistic blocks, while DoT's port 853 is easily identifiable and filterable by network operators.[3] Privacy enhancements set DNSCrypt apart through its optional anonymized mode, where queries route via relay servers that strip client IP addresses before reaching the resolver, breaking direct linkage between user and query data without compromising authentication.[19] DoT lacks native anonymization, relying solely on encryption, which may still permit traffic analysis or fingerprinting via TLS metadata like cipher preferences or handshake timings.[19] Both resist man-in-the-middle attacks when properly implemented, but DNSCrypt's avoidance of TLS reduces exposure to known protocol flaws, such as those in historical TLS versions, though DoT implementations can enforce modern TLS 1.3 for equivalent forward secrecy.[19] Empirical security audits highlight DNSCrypt's battle-tested design since 2011, with no major breaks reported, compared to DoT's integration into diverse TLS ecosystems that have faced exploits like Heartbleed or Logjam in the past.[19]| Aspect | DNSCrypt | DNS over TLS (DoT) |
|---|---|---|
| Transport | UDP/TCP, port 443 default | TCP, port 853 |
| Authentication | Public key stamps, no PKI | X.509 certificates via PKI |
| Encryption | Custom AEAD (e.g., XChaCha20-Poly1305), ephemeral keys | TLS cipher suites (e.g., AES-GCM), session keys |
| Privacy Feature | Anonymized relays optional | None native; encryption only |
| Overhead | Low; UDP stateless, no full handshake per query | Higher; TCP + TLS handshake |
| Standardization | Custom, IETF draft ongoing[5] | RFC 7858 (2016)[18] |
DNSCrypt versus DNS over HTTPS (DoH)
DNSCrypt and DNS over HTTPS (DoH) both encrypt DNS queries and responses to mitigate eavesdropping, spoofing, and tampering, but they employ distinct architectural approaches. DNSCrypt v2 utilizes a lightweight, DNS-specific protocol over UDP or TCP, featuring public-key authentication via Ed25519-signed certificates and symmetric encryption with X25519-derived keys and XChaCha20-Poly1305.[3] In contrast, DoH, standardized in RFC 8484 in October 2018, encapsulates DNS messages within HTTPS payloads using HTTP/2 or HTTP/3 over TCP port 443, relying on TLS for encryption and server authentication via X.509 certificates. These differences yield variations in overhead, with DNSCrypt avoiding HTTP headers and TLS handshakes for initial queries, enabling shorter-lived sessions without persistent connections.[19] From a security standpoint, DNSCrypt emphasizes resolver authentication independent of certificate authorities, using provider public keys to verify short-term session certificates rotated every 24 hours, which reduces reliance on potentially compromised CAs.[3] It also supports experimental post-quantum cryptography prototypes, addressing vulnerabilities in classical schemes like those in TLS. DoH inherits TLS's strengths, including forward secrecy, but exposes risks from insecure cipher suites or CA failures, as seen in historical breaches like the 2011 DigiNotar incident.[19] Both protocols resist man-in-the-middle attacks when properly implemented, though DNSCrypt's explicit key stamps provide verifiable resolver identities without browser trust stores.[19] Performance metrics favor DNSCrypt for latency-sensitive environments due to its minimal protocol overhead—queries padded to 64-byte multiples with no HTTP framing—and UDP compatibility, which avoids TCP's head-of-line blocking.[3] Empirical evaluations indicate DNSCrypt resolves domains faster than DoH in scenarios with high query volumes, as DoH's TLS negotiation and HTTP encapsulation add 10-50 ms delays on cold connections, though HTTP/2 multiplexing mitigates this for subsequent requests.[20] DoH, however, leverages content delivery networks (CDNs) for global anycast routing, potentially reducing round-trip times in distributed setups.[19] Privacy enhancements differ notably: DNSCrypt's anonymized variant generates ephemeral client key pairs per query or session, masking IP-query correlations at the resolver and thwarting tracking across requests.[3] DoH encrypts payloads but transmits over identifiable HTTPS flows, potentially leaking metadata like User-Agent strings or enabling fingerprinting via HTTP/2 stream patterns, though ongoing IETF efforts aim to mitigate this.[19] Neither inherently anonymizes against resolver logging, but DNSCrypt's design minimizes server-side state, limiting data retention compared to DoH's web-server logs.[19] Deployment trade-offs highlight DoH's integration advantages, as it repurposes existing HTTPS infrastructure for easier adoption by providers like Google Public DNS (supporting DoH since 2019) and browsers such as Firefox.[21] This port 443 usage camouflages traffic amid web flows, enhancing censorship resistance in restrictive networks. DNSCrypt, operational since 2011, requires dedicated server implementations but offers flexibility via tools like dnscrypt-proxy, which supports hybrid modes; however, its custom framing makes it more fingerprintable and blockable than DoH.[19] Overall, DNSCrypt prioritizes efficiency and CA independence for embedded or resource-constrained clients, while DoH excels in web-centric ecosystems despite higher complexity.[19]Deployment and Adoption
Software and Client Implementations
The primary reference implementation for DNSCrypt clients is dnscrypt-proxy, a flexible DNS proxy developed by Frank Denis that supports DNSCrypt version 2, along with complementary protocols such as DNS-over-HTTPS (DoH), Anonymized DNSCrypt, and Oblivious DoH (ODoH).[22] Written in Go, it operates across multiple platforms including Linux, BSD, Windows, macOS, and Android, enabling users to route DNS queries through encrypted channels while providing features like load balancing, failover, and blocking of malicious domains via customizable blocklists.[23] The software's latest stable release, version 2.1.14 dated September 3, 2025, includes enhancements such as client IP address encryption in logs using IPCrypt and improved pattern rule documentation.[24] Other notable client implementations include Simple DNSCrypt, a Windows-specific graphical user interface (GUI) wrapper for dnscrypt-proxy, authored by Christian Hermann in C#, which simplifies configuration of DNSCrypt and DoH resolvers without requiring command-line interaction.[25] For broader cross-platform use, SecureDNS by Texnomic extends support to DNSCrypt, DoH, DNS-over-TLS (DoT), and Anonymized DNSCrypt on Linux, Windows, and macOS using C#.[26] Mobile-focused options encompass RethinkDNS for Android, developed by Celzero in Go and Kotlin, which integrates DNSCrypt with firewall and connection tracking capabilities,[27] and Trust DNS by Surfshark, a closed-source app supporting DNSCrypt and DoH on both iOS and Android.[28]| Implementation | Platforms | Key Protocols | Language |
|---|---|---|---|
| dnscrypt-proxy | Linux, BSD, Windows, macOS, Android | DNSCrypt v2, DoH, Anonymized DNSCrypt, ODoH | Go |
| Simple DNSCrypt | Windows | DNSCrypt, DoH | C# |
| SecureDNS | Linux, Windows, macOS | DNSCrypt, DoH, DoT, Anonymized DNSCrypt | C# |
| RethinkDNS | Android | DNSCrypt | Go, Kotlin |
| Trust DNS | iOS, Android | DNSCrypt, DoH | Proprietary |
Public Resolver Support
Public DNSCrypt resolvers provide users with encrypted DNS query resolution through the protocol's authentication and encryption features, often alongside DNSSEC validation and no-logging commitments. These services are operated by independent organizations, companies, and individuals worldwide, enabling clients like dnscrypt-proxy to connect securely without relying on unencrypted or ISP-provided DNS.[14][30] A comprehensive, regularly updated list of such resolvers is curated by DNSCrypt project maintainer Frank Denis, encompassing hundreds of endpoints supporting DNSCrypt v2 and compatible protocols like DNS-over-HTTP2. As of October 2025, the list includes approximately 900 public servers when combining DNSCrypt with DNS-over-HTTPS options, though pure DNSCrypt endpoints number around 140-230 depending on filtering criteria such as DNSSEC support or anonymization compatibility.[31][30] Many resolvers emphasize privacy through no-query-logging policies, but users must verify individual entries, as some incorporate ad-blocking, malware filtering, or potential data practices that may conflict with strict no-logs requirements; the list warns of inclusions with censorship or monetization risks, recommending client-side filters likerequire_dnssec=true.[31]
Notable examples include dnscry.pt resolvers in locations such as Montreal (Canada), Moscow (Russia), and Mumbai (India), which offer uncensored, unfiltered service with IPv4/IPv6 support, DNSSEC, and no stored logs.[32] Other operators provide specialized features: Andrews & Arnold LTD in the UK maintains non-filtering, no-logging resolvers with DNSSEC; AdGuard DNS blocks ads and malware but is incompatible with anonymized queries; and digitale-gesellschaft.ch in Zurich (Switzerland) prioritizes non-filtering and privacy without logs.[31] These resolvers facilitate global distribution, with concentrations in Europe, North America, and Asia, allowing dnscrypt-proxy users to select based on proximity, load balancing, or policy via automated stamp downloads from the project's GitHub repository.[30][33] Mainstream providers like Cloudflare appear in lists for anycast support but prioritize DNS-over-HTTPS/TLS over native DNSCrypt, highlighting DNSCrypt's niche among privacy-centric alternatives.[31]