Normal DNS queries and responses are not encrypted. However, there are many technologies hoping to change that; some of these are proprietary solutions, some are emerging standards. We will discuss each briefly in this article.
Before any specific DNS encryption solutions exist, there is always the generic VPN (virtual private network), which will encrypt not just DNS traffic, but all traffic on the wire. There are literally hundreds and thousands of different VPN products that can provide privacy beyond encrypted DNS traffic, so if overall privacy is your concern, choosing a VPN product might be more efficient than choosing a way to encrypt DNS messages.
DNSCurve is a proprietary solution invented by the security researcher Daniel J. Bernstein, who famously created the djbdns DNS software packages with a focus on security. Dr. Bernstein proposed DNSCurve as a replacement technology for DNSSEC, to provide authentication, data integrity, and privacy all in one. The strength of DNSCurve is that it provides stronger and more efficient use of cryptographic keys than DNSSEC, and provides complete privacy among DNS server communications. However, not being a published IETF standard made it difficult for vendors to deploy and implement. As of 2019, it has not been deployed widely enough for the industry to pass judgement whether or not this is a viable technology.
DNSCrypt addresses the “last mile” problem between the DNS client and server. It encrypts unmodified DNS traffic over port 443 (not using HTTP) and requires special client and server software to be installed. DNSCrypt currently is being offered by OpenDNS (now part of Cisco) as a service, as well as a few other service providers. While the specs and source code of DNSCrypt are open and free to inspect, it has never been written as an IETF standard RFC, making it “non-standard” in some people’s eyes.
Somewhat similar to the VPN approach, this IETF draft proposes a new setup where clients can fetch and verify the IPSEC identity by querying the DNS server (through the use of DNSSEC-DANE) and uses opportunistic encryption to establish an IPSEC tunnel to the DNS server. The prerequisite of this approach is to have full DNSSEC deployment. This proposal is only a draft and should be treated as “experimental” at this point.
This IETF draft advocates for the publishing of the DNS server’s encryption key, so that when a client connects, the client can obtain the encryption key from the DNS server, then use the encryption key to secure all communication from that point on with the server. The pre-requisite is that the encryption key from the server is authenticated and not spoofed, which requires an authentication mechanism such as DNSSEC. Just like IPSECA, this is only a draft and should be treated as “experimental.”
DNS over TCP (DoT)
This new standard (RFC 7858) sends encrypted DNS traffic over TCP port 853. As of 2019, many vendors have started providing support for DoT both on client and server side. This protects the “last mile” between client and server, while it can also be used to protect server-to-server communications. DoT can be deployed as a compliment to DNSSEC. To learn more about DoT.
DNS Over DTLS
Similar to DoT, this new standard (RFC 8094) sends encrypted DNS traffic over UDP port 853. This technology addresses all of the same issues as DoT and behaves the same as DoT, with the exception of using DTLS for encryption over UDP.
New – DoH (8484)
This new IETF standard (RFC 8484) wraps DNS traffic within an encrypted HTTPS session, protected by TLS for “last mile” privacy. It runs over the standard TCP port 443, and most implementations embed the client in the web browser. To learn more about DoH, click DoH.
Whatever product or solution you choose, remember that encryption is an end-to-end technology, so you still need to trust the other end. Just because the DNS communication between you and your ISP is encrypted, it doesn’t protect your privacy if your ISP just turns around and makes your DNS data available to the entire world. Additionally, if DNSSEC is not in place, the information you received over the encrypted channel can still be spoofed somewhere upstream, and you may still be prone to DNS cache poisoning or hijacking attacks.