5

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

Ninja Bug
  • 153
  • 1
  • 4
  • 1
    Currently? Mostly no. That's changing, though. https://en.wikipedia.org/wiki/DNS_over_HTTPS https://en.wikipedia.org/wiki/DNSCrypt https://arstechnica.com/information-technology/2018/04/how-to-keep-your-isps-nose-out-of-your-browser-history-with-encrypted-dns/ – ceejayoz May 19 '18 at 19:43
  • 1
    DNS can use either UDP or TCP, and TCP support is required for DNS. From _[RFC 5966, DNS Transport over TCP - Implementation Requirements](https://tools.ietf.org/html/rfc5966)_: "_This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation._" – Ron Maupin May 19 '18 at 20:55

2 Answers2

11

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:

Community
  • 1
Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42
  • Regarding *authenticity (being sure you get a response from the true nameserver you queried)*, solving it in those specific terms would not be very practically useful for DNS. DoT, DoH, etc alone would satisfy that, but DNSSEC does a significantly better job for authenticity since it protects the data itself rather than just one connection. Ie, it ensures who the data originated from (zone owner) and that the data is unmodified, regardless how many intermediaries are in place. (Usually there is at least one intermediary system, which is why DoT, DoH, etc give more limited protection (one hop). – Håkan Lindqvist May 20 '18 at 08:52
  • @HåkanLindqvist Yes I have changed for "authoritative nameserver". DoT and DoH assures authenticity of the last hop, where DNSSEC is accross all hops. – Patrick Mevzek May 20 '18 at 16:33
6

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.

theultramage
  • 393
  • 1
  • 4
  • 14
  • 4
    "but still not encrypted": encryption was never a goal of DNSSEC. Contrary to intuition, authenticity is more important than confidentialit, hence DNSSEC was created to assure authenticity. Also there is EDNS for larger packets in DNS: Using TCP does not provide anything regarding encryption. – Patrick Mevzek May 20 '18 at 00:33