Are DNS queries encrypted?

I wonder if DNS queries are encrypted. If so, can you briefly explain the process as I suppose for an encryption to take place, there should at least be a minimum common ground between two parties (like a share of a key), but since DNS uses UDP and it is connectionless, I cannot imagine how you can encrypt your payload in this case.

Thanks

Solution 1:

Standard DNS is not encrypted anywhere. DNSSEC has cryptographically signed (but still not encrypted) responses. There have been some non-standard ideas and implementations over the years, but nothing major.

DNS should also work over TCP, since it is the standard mechanism for dealing with answers that are too big (the alternative is IP fragmentation). The server essentially sends an UDP response saying 'answer too big, try again over TCP'.

Regarding your question, a straightforward but slow solution would be to do the same thing HTTPS does - do a three-step TLS handshake, validate the certificate somehow, and then exchange the data. The real challenge is to reduce the number of roundtrips while still providing some form of security.

Solution 2:

DNS, by default and when created, does not offer neither authenticity (being sure you get a response from the true authoritative nameserver of the zone) nor confidentiality (making sure no one on the wire can understand your query or your answers).

DNSSEC was created to solve the authenticity problem, because it allows one to sign records, and through a mechanism of keys you build a chain of trust and can verify the answers you get. It solves the Man In the Middle problem in the sense that, if the concerned zone is signed (which is still around 0.53% of all zones nowadays) and if someone tries to change the replies for such a zone, then you will be able to spot the changes.

Authenticity is more important than confidentiality, contrary to intuition. Why? Because if you have no guarantee who you are talking too, even if the answer comes to you encrypted, what value does it have? You can be doing encryption with any evil third party if you do not authenticate it.

It is true now that if you already have authenticity, because of DNSSEC for example, you may wish to have confidentiality as DNS can convey sensitive or at least personal information. This is also why QNAME minimization now exists, to reduce the quantity of information sent to each nameserver. This is more and more supported (soon in Bind)

So now as for encryption, your first error is to think about UDP. DNS uses UDP and TCP, and nowadays even more often TCP for the reasons we will see below. That aside, note that even for UDP, you have encryption options, see DTLS, which is basically TLS in UDP. QUIC, created by Google (basically to be able to create an optimized HTTP, which became now HTTP/2 after having been SPDY), was also built over UDP with securities being similar to what TLS offers. Have a look at this two to debunk your idea that a payload could not be encrypted in such case.

Today for encrypted DNS you have these options in no specific order:

• DNSCrypt: this is not a standard in the IETF sense, but it an open protocol, implemented by various actors. See https://dnscrypt.info/
• DNS over TLS is now a standard (RFC7858 and RFC8310), and you have various document explaining how the initial handshake should take place, see the second RFC above and the two security profiles defined and also note how and when DANE could be useful, where DANE mandates the use of DNSSEC; next version of Android will support DNS over TLS by default (see https://security.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html), even if it uses for me a slight misnomer of "private DNS".
• DNS over HTTPS (which itself uses TLS then) is not yet an IETF standard but is in the way of becoming one.
• Oblivious DNS is the newest kid on the block, which needs both newer clients and servers to use it, as well as the new odns TLD.

Of course in all these cases you need to have specific servers speaking the protocol. Some open resolvers are already offering DNS over TLS. You however only shift your problem: your connection is "secured" up to them but then you have to trust them to work correctly and not lie to you, specially in validating DNSSEC.

You can:

• search on https://dnscrypt.info/public-servers/ for a list of servers supporting the DNSCrypt protocol, or look on https://github.com/DNSCrypt/dnscrypt-resolvers/blob/master/v2/public-resolvers.md
• use currently either CloudFlare, Quad9 or CleanBrowsing open resolvers on port 853 for DNS over TLS, or have a look at https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers for some list or https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers
• use currently either CloudFlare, Google Public DNS or CleanBrowsing, which offering DNS over HTTPS, or again at https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers for some list.