Unlike HTTP and Web privacy, the issue of privacy for DNS users was never a hot topic. There are no specific rules or regulations about it, and the typical Data Protection Agency, GDPR or not GDPR, is not too interested in the subject. But DNS traffic can be very revealing and has already been used to identify things such as malware communicating with a C&C. If DNS surveillance can be done for the good, it can certainly also be done for evil purposes.

This is what motivated the Internet Engineering Task Force to start a work at the Vancouver meeting in november 2013, with a more official start at the London meeting in march 2014. The project followed the classical steps: describing the problem, the threat model, the actual rissk (this is now documented in RFC 7626), then trying to find solutions. While many geeks, when asked about privacy, immediately scream "encryption", privacy actually requires TWO things: encryption to protect against third parties, AND data minimisation, to protect you against the servers you talk to. Hence the development of two solutions, encryption with TLS (RFC 7858) and QNAME minimisation (RFC 7816).

There is also running code. The Unbound DNS resolver already knows how to encrypt (upstream and downstream), and can also perform QNAME minimisation, like the Knot resolver. The excellent getdns library also speaks DNS-over-TLS, allowing things like a monitoring plugin to monitor your DNS-over-TLS servers. Android has now DNS-over-TLS in its code base.

And there are some public deployments with this technology. The OpenWrt router Turris Omnia already ships, by default, with QNAME minimisation enabled. The Quad9 public DNS resolver accepts DNS-over-TLS.

What can we expect in the future? There are some projects to allow encryption between resolver and authoritative server (RFC 7858 only cobvers the stub-to-resolver case), to add padding to more TLS requests (getdns and Knot already do it), but most of the work will probably be on the code and deployment.