Conclusion of “DNS privacy” at IETF

Some context on the DNS

The DNS (Domain Name System) is a critical Internet service. Starting from just a domain name, it allows technical information such as IP addresses, which are indispensable for the vast majority of Internet activities, to be recovered.¹ But since nearly all Internet operations start with a DNS query, the DNS is also a source of information for the many people seeking to keep watch on users’ activity. Indeed, one of the NSA’s quaintly named programmes brought to light by Snowden was dedicated to surveillance of the DNS: “more cow bell”.

The danger posed by surveillance is all the greater in that the processing of a DNS query goes through several servers, some of which may be remote.² What’s more, many people have very limited knowledge of the Internet infrastructure and, as a result, the risks to privacy associated with the DNS are often poorly understood. Unlike the privacy issues associated with the Web, which have been the subject of countless articles and debates, those associated with the DNS are often overlooked.

Some people seek to downplay the risk by claiming that a DNS query does not give away much information, only the domain name that the user is interested in. If the name is en.wikipedia.org, there’s no real problem, since nearly everyone uses Wikipedia. But if the name is www.alcoholics-anonymous.org.uk, we’re into more sensitive territory.

Finally, a couple of technical points. First, contrary to almost all Internet application protocols, the DNS did not use any encryption,³ all communications being in clear text. The second point is that the DNS resolver traditionally sent the whole name requested to all the authoritative servers that it contacted. If a user wished to visit www.phy.cam.ac.uk, the root servers saw the whole query whereas the TLD (Top-Level Domain, in this case .uk) would have sufficed.

Some context on the IETF

The IETF (Internet Engineering Task Force) is one of the Internet standards organisations; in other words it lays down technical standards which allow the Internet, with its many and varied types of hardware and software, to function smoothly. It is particularly active in the software infrastructure of the Internet, so not the hardware or the applications that the user sees, but everything in between the hardware and the applications, including notably the DNS.

The IETF is organised in working groups, each responsible for a particular subject.⁴ One characteristic that sets the IETF apart from many other standards organisations is that the vast majority of these working groups are temporary. They are set up for a specific task, given formal recognition in a charter, and disbanded once the task has been completed or abandoned. A working group is disbanded either because there is insufficient interest in the project, the IETF consisting as it does of volunteers, or because the problem addressed proves insoluble, or in any case no consensus can be reached. But the end of a working group doesn’t necessarily mean failure: it may mean that the objectives set out in the group charter have been attained.

History of the project

Returning now to the DPRIVE (DNS PRIVate Exchange⁵) working group, its origins date back to 2013, a few months after Edward Snowden’s revelations. On a flight to Vancouver for an IETF meeting in which the issue of combating mass surveillance was to be the main topic,⁶ a number of DNS specialists, among them yours truly, discussed this and reached the conclusion that something had to be done for the DNS too. Several ideas emerged, in particular the importance of walking on two legs, by encrypting communications but also by minimising the data transmitted. By the time we landed, the project had been agreed.

In Vancouver, the project had only been discussed informally. A few days later, on 12 November 2013, the first draft for discussion was published, draft-koch-perpass-dns-confidentiality. On 27 November 2013, a second draft for discussion of the problem was made available. It was called draft-bortzmeyer-dnsop-dns-privacy and, as always with the IETF, where everything is public, its history can be followed online. As a reminder regarding the IETF, anyone can write a draft and have it published. Nothing is checked except grammar and spelling. So at the time these documents had no official status.

Another important step was taken in London, in March 2014, at another IETF meeting in which a BoF⁷ was held. A BoF is a meeting aimed at defining a problem. Most of the IETF working groups were set up following a BoF. BoFs are specified in RFC 5434. The London BoF met under the name DNSE (for DNS Encryption), an unfortunate name in that it focused on a solution rather than the problem itself, and made no mention of the minimisation of data, which is often overlooked in discussions on the protection of privacy. Several participants were opposed to the project, with traditionalist arguments along the lines of “that’s how things have always been done” and downplaying the threats to privacy, which is the traditional U.S. stance. Nevertheless, the BoF was a success, in spite of these few objections, and the work continued. On 11 March 2014, the DNS privacy list⁸ was drawn up as an aid to discussion, and the first message read “Welcome to the DNS privacy list. This is where we’ll have those discussions surrounding DNS privacy and confidentiality.”

The DPRIVE working group was finally set up on 16 September 2014, with a charter indicating that it was to work on a description of the problem and on solutions, which were not initially specified. One important constraint was that compatibility with the existing DNS had to be maintained. So there was no question of developing a protocol to replace the DNS. A first draft was adopted by the working group and published on 26 October 2014. It became an official working document of the group, the draft-ietf-dprive-problem-statement, and was later to become RFC 7626. This group’s first RFC, which gave a detailed description of the problem to be resolved, was followed by ten more RFCs, which in particular standardised several ways of encrypting DNS communications, such as RFC 7858, in 2016, which standardised DNS over TLS (DoT⁹).

It should be noted that DPRIVE was not the only IETF working group to work on the protection of DNS privacy. The minimisation of queries (QNAME minimisation, in which the authoritative servers are sent only part of the domain name queried by the user) was covered by an existing working group, DNSOP, which published RFC 7816 in March 2016, a first draft, draft-bortzmeyer-dns-qname-minimisation, having been published two years previously.¹⁰ And another working group was also involved: DoH (DNS over HTTPS), which focused on standardising DoH in RFC 8484 in October 2018.

As well as various technical problems,¹¹ the project encountered a number of different difficulties. There were those who opposed encryption in principle, blaming it for reducing operators’ visibility, and patent issues too. (Yes, a patent had been filed on query minimisation!). As with most software patents, this was nothing new, the technique having already been used, but not always well documented and therefore not easy to prove. There were also some unfounded concerns, such as the fear that query minimisation could break the existing DNS.

Once the first three, essential RFCs, 7626, 7816 and 7858, had been published at the end of 2016, the DPRIVE working group became much less active. Still, there were some useful additions, such as the “padding” of encrypted communications, in RFC 8467 and the description of DNS servers’ privacy policies in RFC 8932. And new versions of original RFCs were also published. In some cases, the replacement was technical – for example RFC 7818 was replaced by RFC 9156, with a slightly different algorithm based on experience acquired in the meantime. In other cases, it was political, to take account of the usual criticisms levelled against encryption, for example that it reduces the possibilities of surveillance (which is indeed its aim). And some ideas, such as encrypting communication between the resolver and the authoritative servers,¹² fizzled out despite several attempts. Since the IETF works on a voluntary basis, the usual practice when work does not move ahead is to close down the working group and wait for the next opportunity. The DPRIVE working group was therefore disbanded on 11 July 2025, after just over ten years of existence.

As you will have remarked from this article, the IETF is highly transparent. All the official work is done in public and filed,¹³ which proved particularly handy when it came to writing this article.

The results

For an IETF project, “DNS PRIVate Exchange” was a relatively short one. Between the first official meeting, the London BoF, and the publication of the three essential RFCs, a total of just over two years elapsed. For a collective effort involving dozens of people from different countries and with different opinions, that’s not bad going. And people say the IETF’s internal procedures are slow and rigid!

The bulk of the work consisted in drawing up the three RFCs, 7626 which described the problem, 7816 on minimising queries and 7858 on encrypting the DNS. The technical standard was not just written – it has been widely deployed since. Query minimisation is now implemented on all resolvers, and often activated. A test carried out with RIPE Atlas probes in France in November 2025 showed that the vast majority of resolvers make use of this minimisation.

Consumer operating systems like Android have an integrated DoT client (Microsoft Windows 11 uses DoH) and all public DNS resolvers accept DoT and DoH.

In short, the “DNS PRIVate Exchange” project was a success, first of all in that it succeeded in drawing attention to the issue of DNS privacy, and secondly in that it allowed first the honing and then the deployment of techniques for improving the protection of privacy.