As we sit here, writing or reading this article, several large-scale Internet companies, including Apple, Mozilla, Microsoft, and Google, are in the process of implementing DNS over HTTPS (DoH) into services and applications. ISC, the manufacturer behind Bind 9, will also be rolling out a new version this autumn that is DoH-capable. And it can be assumed that more will follow suit in the coming months. This has had the effect of catapulting that what may seem to be a really geeky niche topic – a mechanism for encrypting information about use of the Domain Name System (DNS) – into the spotlight.
DoH – what’s it all about?
What does this mean to the average user? Well, let’s start with the DNS part: If you surf or browse the Internet or ever use any resources (e.g. company file storage) on the Internet, you typically reach them by entering the “name” of the resource that you would like to use. Now, machines are not very good at names. They use numbers. And the Domain Name System’s job is to translate names to numbers and vice versa (a process known as domain resolution). The DNS is something that the average user rarely spares a thought for, and it used to be something configured and hidden very deeply in the innards of your operating system.
And this is part of what DoH changes in its approach to domain resolution. With DoH, the web protocol HTTPS is used to transport DNS requests, which offers the security of an encrypted service, and it also means that name resolution is not only possible in the operating system, but also in applications. This was actually the starting point for DoH – with applications performing their own DNS and ignoring the settings in the operating system, which also kick-started a lot of the controversy surrounding DoH. But the pace of development is such that, within 2 years since the DoH protocol was first tabled, at least four different approaches to implementation have emerged, each attempting to overcome some of the issues with the previous version. This is part of the reason why the eco Association recently published a discussion paper on the topic, to clarify some of the complexities.
DNS privacy in the American context
There are many reasons why this protocol – or more to the point, the way it has been implemented – has become such a controversial subject. To understand the multiple perspectives, first of all we have to look at the original motivation for developing DoH. This was driven from the perspective of the American market environment, where, not only had the Snowden revelations rocked confidence in electronic communications, but also Internet service providers often use their provisioning of DNS services as a way to eavesdrop on what their customers do online. This is not very popular, certainly amongst privacy advocates, but it is quite common. The providers sell the knowledge gained about user behavior to companies that use the information to, for example, analyze behavior and approach individual users with sales messages. (On a side note, which will become important later in this story, this business model is not prevalent in the European context.)
To counteract what is seen as an intrusion on user privacy, American browser manufacturers – that is, Google and the Mozilla Foundation – came up with a solution through the invention of the DoH protocol and by hardcoding into their browsers the DoH services that should receive the users’ DNS queries, and choosing selected services that met their privacy requirements. As a result, nobody else can see what the user is querying for, which would alleviate the problem of the selling of behavioral data. It also helps with security, by protecting the user against man-in-the-middle attacks (MITM) – in which users’ DNS responses are manipulated to send the user to a spoof website (e.g. a fake bank), where they unknowingly give away their credentials to cyber criminals.
When we talk about DoH, it is often in the context of browsers. But actually it could be any application – and, in more recent implementations, the operating system – that uses the DNS. This is something we put an extra emphasis on in the discussion paper – we wanted to move the discussion away from just the browser manufacturers, because any service in the computer that uses the DNS could use DoH.
In sum, there are a number of advantages to the concept of DoH, in that it is designed to support user privacy and security through encrypting DNS. These are topics that the eco Association is strongly in support of.
So far, so good.
User control of their data
However, there are also downsides the way DoH implementation was initially handled, and these have caused controversy – at least in the European context. In the early implementations, the browser developers hardcoded which provider should receive the DNS queries into the application. The problem is that this simply passed over the control of DNS into somebody else’s hand, rather than giving control to the user – not only that, but it also posed a problem for legal blocking of web content, like child sexual abuse material, in jurisdictions where this is handled through the DNS. Opponents to DoH argued that this was just “out of the frying pan into the fire”.
As a result, there was a fair amount of opposition to DoH, especially in Europe, because the criticism was that the user doesn’t have control over where their queries go to. This has been changing gradually, as more providers are added to the lists of approved DoH providers by the software developers (but with manual approval processes, the progress here has been slower than developments in other areas). In the meantime, new implementations have been surfacing which neutralize some of the early criticisms.
The basic message of the eco discussion paper is that any application or operating system using DoH should comply with a range of best practices. From my perspective, the most important one is that DoH should not be hard-coded into applications – there is a need to be able to configure and control where the queries go to. This touches on a range of topics, but two of the burning issues here are giving the user sovereignty over their data, and giving network operators (e.g. for a corporate network, but not only in that context) the ability to enforce important security policies to ensure the security of their systems. The paper also calls for a mechanism that makes sure that users actually find it easy to undertake such configurations. You know, it doesn’t help to say, yes, sure, you can configure it, but it’s hidden somewhere in deep dark recesses in the operating system – regular users simply won’t do it.
Avoiding a single point of failure
A further point which has caused rumblings in the industry is that this changes a basic paradigm of the way the Internet was designed. Something that we at eco fundamentally support is the decentralized structure of the Internet. Too much information placed into a single hand or into a small group of hands may well become a single point of failure – but at the very least it can lead to tipping the balance of power away from the Internet’s more neutral, distributed nature. As a result, there is great motivation in the industry and at eco to keep the Internet decentralized.
This is not even to suggest that these hands necessarily want such power - they may be well-intentioned. It’s just a logical result of only having a limited range of options that these options gain the balance of power. What is important here is to make sure that a wide and diverse range of providers can offer DoH resolution, and that users have the option to choose which provider in which context should process their DNS queries.
The Internet Engineering Task Force (IETF) has now set up a further working group to work on developing mechanisms that will allow DoH providers to be automatically discovered – which should, in the end, do away with the need for any manual approval processes, and result in growing diversity in this market.
Choosing a DoH provider – the changing landscape of DoH provision
What do users need to be aware of in choosing to use DoH? Basically, if you are concerned about privacy and control of your DNS, and choose to use DoH, then make sure you know which provider you are asking for DNS resolution. If you don’t want your queries to go overseas, or across borders, choose a provider you would like to use that is close to you. If you get an extra service from your existing provider on the basis of them having access to your DNS requests, you might want to leave it with that provider.
For example, we have a growing community in our eco Association Anti-Abuse Working Group that analyze DNS queries and try to figure out if customers have machines that have been compromised. It is possible to tell by checking DNS queries against a list of resources that are known to, for example, harbor malware. If your provider offers an extra service on top of DNS resolution to protect you and your computers from downloading malware, you might want to keep your software pointed in the direction of your provider’s DoH resource, so they can still keep providing this service, and in this way keep you out of trouble.
As of now, there are not many providers offering DoH, which currently limits user choice. One reason for this is manual approval processes, but another is the several variations on the theme of DoH that have emerged, and the desire to wait and see which one ends up with most market participants.
A further reason is that DNS resolution is a very performance-intensive task that needs to be done by specialized software. And it will take software developers some time to add the functionality of DoH on top of the original underlying software. So there is not yet a lot of DoH-capable software out there today. They’re set to start hitting the market this autumn. And before we see many providers offering DoH resolution services, we’ve got to have applications which enable DoH. And then as a flow-on effect, we should see more and more providers offering DoH resolution.
The eco Association Discussion Paper on DoH – bringing diverse parties to the table
In essence, the message of eco’s discussion paper is that DoH is good. It is an improvement in terms of privacy, as long as the users get control over where the queries go. Developing the paper was an exercise in finding consensus. We managed to bring parties to the table that have very strong opinions and very opposing opinions. And we were able to find a compromise, which I think is very important. The parties we were able to bring together – all members of the eco Association – included not only vocal privacy advocates like Open-Xchange and Power-DNS, but also companies from the ISP and telco sector, like Deutsche Telecom, and the web infrastructure company CloudFlare, who was one of the first providers to work together with Mozilla on their implementation.
If we want to actually achieve something as a community – and the Internet is a community – it doesn’t help to simply put your foot down and refuse to talk to your adversaries. You can do that if you are on your own, but you can’t do that as a participant in society or in a market. So it is important to be able to find a compromise, which I think we achieved. I don’t want to judge if it’s really the best compromise that I can think of. I think the fact that we’ve been able to bring the people to a table that have not been talking to each other previously and get them to agree on a compromise is a success in itself.
The power of compromise
The thing about compromise is that it’s painful for everyone. There is a brilliant speech by the former German Chancellor Helmut Schmidt for the Global Ethics Conference in 2007 about the ethos of politicians. In it, he commented that “Without compromise, no majority consensus can be achieved. Anyone who on principle is unable or does not want to work towards compromise has no place in democratic law-making.” I agree – because you won’t be able to achieve anything. It’s all about compromise.
So, what’s next? From my perspective, what would be the most important thing to achieve as a next step in the evolution of DoH is a standard for auto configuration that allows system administrators within a certain context – that could be a provider, but it also could be your company network – to establish a context where your applications auto-configure themselves to use particular DoH services. And of course, software that is built should adhere to this configuration standard. They should implement it and implement it correctly. If we have this, we will have all the privacy that we want, with the control that we demand. This will encourage a diverse landscape of DoH provision, and give users the power to decide what happens to their data.
Patrick Koetter is an email expert, and a board member of sys4 AG, which is specialized in email, DNS, and the development of highly secure platforms and services. He contributes his knowledge and experience to eco as an expert and as Leader of the Competence Groups Email and Anti-Abuse.