DNSCrypt

DNSCrypt is a network protocol designed by Frank Denis and Yecheng Fu, which authenticates Domain Name System (DNS) traffic between the user's computer and recursive name servers.

Although multiple client and server implementations exist, the protocol was never proposed to the Internet Engineering Task Force (IETF) by the way of a Request for Comments (RFC).

DNSCrypt wraps unmodified DNS traffic between a client and a DNS resolver in a cryptographic construction in order to detect forgery. Though it doesn't provide end-to-end security, it protects the local network against man-in-the-middle attacks.[1]

It also mitigates UDP-based amplification attacks by requiring a question to be at least as large as the corresponding response. Thus, DNSCrypt helps to prevent DNS spoofing.

DNSCrypt can also be used for access control, as done by Comodo in their cDome Shield product.

Deployment

In addition to private deployments, the DNSCrypt protocol has been adopted by several public DNS resolvers, the vast majority being members of the OpenNIC network, as well as virtual private network (VPN) services.

OpenDNS (now a part of Cisco) announced the first public DNS service supporting DNSCrypt in December 2011, shortly followed by CloudNS Australia.

On March 29, 2016, Yandex announced support for the DNSCrypt protocol on their public DNS servers, as well as in their web browser.

Later, Infoblox announced ActiveTrust Cloud, leveraging DNSCrypt to secure DNS communications.

On October, 2016, AdGuard added DNSCrypt to their DNS filtering module so that users could move from their ISPs to custom or AdGuard's own DNS servers for online privacy and ad blocking.[2][3]

Quad9 public DNS resolver service run by the not-for-profit organization contributed by IBM, Packet Clearing House, and Global Cyber Alliance announced support for DNSCrypt in September 2018.[4]

Other servers that support secure protocol are mentioned in the DNSCrypt creators’ list.[5]

Protocol

DNSCrypt can be used either over UDP or over TCP. In both cases, its default port is 443, even though the protocol radically differs from HTTPS.

Instead of relying on trusted certificate authorities commonly found in web browsers, the client has to explicitly trust the public signing key of the chosen provider.

This public key is used to verify a set of certificates, retrieved using conventional DNS queries. These certificates contain short-term public keys used for key exchange, as well as an identifier of the cipher suite to use. Clients are encouraged to generate a new key for every query, while servers are encouraged to rotate short-term key pairs every 24 hours.

Queries and responses are encrypted using the same algorithm and padded to a multiple of 64 bytes in order to avoid leaking packet sizes. Over UDP, when a response would be larger than the question leading to it, a server can respond with a short packet whose TC (truncated) bit has been set. The client should then retry using TCP and increase the padding of subsequent queries.

Versions 1 and 2 of the protocol use the X25519 algorithm for key exchange, EdDSA for signatures, as well as XSalsa20-Poly1305 or XChaCha20-Poly1305 for authenticated encryption.

Public-key based client authentication

The DNSCrypt protocol can also be used for access control or accounting, by accepting only a predefined set of public keys. This can be used by commercial DNS services to identify customers without having to rely on IP addresses.

See also

References

  1. ↑ "DNSCrypt Proxy README.markdown". Github.
  2. ↑ "AdGuard DNS Now Supports DNSCrypt".
  3. ↑ "DNS Filtering Android".
  4. ↑ "DNSCrypt Now in Testing".
  5. ↑ "DNSCrypt Resolvers".
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.