An Update on Developments with DNS-over-HTTPS

The development of encrypted DNS, specifically DNS-over-HTTPS (DoH), has attracted a relatively large amount of interest to a previously quiet corner of the Internet protocol world. Its development has been driven by a desire to show full end-to-end encryption of network connections, removing one of the remaining elements of plain text data.

The DoH protocol has been deemed complete by the Internet Engineering Task Force (IETF) and the DoH working group was wound up in March 2020. However, the absence of both resolver discovery and selection mechanisms meant that the protocol was lacking some key elements to aid adoption, a shortcoming that may be addressed in due course via the IETF’s recently constituted ADD working group.

Where are the DoH clients?

A protocol like DoH is only useful once client software emerges, with particular interest being paid to browsers and operating systems.

Firefox

With the first relatively mainstream implementation of DoH, Mozilla’s Firefox browser broke new ground when it enabled connection to the Cloudflare resolver by default. This approach was tried first in North America and is currently restricted to that market, with deployment in this manner apparently tempered by early criticism of the approach, especially in Europe.

Currently Firefox supports a very small number of DNS resolvers, all of which are operated by US companies (Cloudflare, Comcast and NextDNS). It is possible for a user to manually configure alternative DNS providers. However, whilst relatively straight forward to do, it requires more knowledge of the Internet than most users are likely to possess (for example, most people have no awareness of the DNS nor of its function). Where the user has been connected to a DoH resolver automatically, the software will switch back to regular DNS if that resolver becomes unavailable.

Once DoH is enabled in Firefox, users may bypass any local DNS filtering that, for example, is used to implement parental controls or to stop access to malicious content or, in an enterprise environment, to implement corporate content policies.

Note Mozilla claims that Firefox will check for the existence of certain functions including whether parental controls are enabled, whether the default DNS server is filtering potentially malicious content or if the device is managed by an organization that might have a special DNS configuration. In such case, DoH should not be enabled. However, there are different methods to implement these functions so it is possible that the detection may not work in every case.

In addition, any locally required DNS content blocking, for example of illegal or copyright infringing content, will be bypassed.

Google and Microsoft

Google and Microsoft have taken similar paths to each other in the way that they support DoH in the Chrome browser and Windows 10 respectively. DoH-enabled Chrome clients are already readily available whereas DoH support is only included in the Windows Insider software at present. Industry rumours suggest Microsoft software will move to the mainstream in the first half of 2021.

Where Chrome or Windows automatically enables a connection to a DoH resolver, it will only do this where the software establishes that the user’s current DNS provider has a DoH option and is part of its auto-upgrade program (the so-called ‘same provider auto-upgrade’ or SPAU approach). As both the existing DNS and the proposed DoH variant are being provided by the same resolver operator, the assumption is that both will provide the same functionality including any filtering and blocking. In other words, the user experience should be unchanged from a DNS perspective. As with Firefox, it is possible to manually configure other DoH options, again noting that it’s unlikely that most users will do this.

Both Google and Microsoft provide tools for enterprises to configure or block the use of DoH by the Chrome browser and by Windows 10 respectively. This will either lock down the settings to a preconfigured resolver or may even switch off the capability. Where the user has been connected to a DoH resolver automatically, the software will switch back to regular DNS if the DoH resolver is not available (this is not the case if the resolver has been configured manually).

Apple

In the case of iOS 14, support for DoH (and DNS-over-TLS) is included in the operating system but does not take effect unless:

• The device owner (enterprise) specifies a default DoH resolver.
• A VPN is in operation and is configured with a DoH resolver.
• The user of the device specifies a default DoH resolver.
• Individual applications specify a DoH Resolver.

Where more than one of these is in place, they are listed in descending order of priority: for example an application’s preference will be overridden by an enterprise setting.

Since iOS does not connect the use to a DoH resolver by default, there is no bypassing of filtering or blocking unless one of the entities in the above list takes an explicit step to enable DoH.

What about resolver support?

A number of early adopters have emerged amongst the resolver community, with cloud-based resolvers in the vanguard including Cloudflare, Quad 9 and NextDNS.

These have been joined by a growing number of ISP-led implementations, with Comcast seeing a growing volume of usage in the USA and several European ISPs moving forward with trial deployments including Deutsche Telekom in Germany and BT Group in the UK.

One challenge that has emerged for ISP resolvers is that the architecture used in Europe is very different to that in the US. European ISPs typically employ a DNS forwarder in the ISP’s router, often paired with a home network architecture that uses private IP addresses. Because of the difference between typical ISP implementations in Europe vs the US, the current mechanisms employed by client software to implement SPAU do not work for European ISPs.

The result of the differing architectures is that encrypted DNS traffic is growing relatively quickly to cloud resolvers and to those resolvers operated by some US ISPs, whereas traffic to the trial resolvers operated by European ISPs is very light, with test traffic the exception. Some client software companies appear reluctant to amend their interim discovery solutions to work in the European market, preferring instead to wait until a standard discovery solution has been agreed through the IETF working group, possibly in the next two to three years.

The current difficulty in being able to easily identify and choose encrypted DNS resolvers is a concern, not least because of the detrimental effect on user choice. In addition, anything that appears to drive further centralization of Internet traffic, potentially undermining resilience, needs careful examination.

Is privacy enhanced by DoH?

Given that the original intention of encrypted DNS was to improve the privacy and security of the DNS for users, this is worthy of review. Some areas of concern have come to light that still need attention, including:

• Resolver Settings – there is a tension between enhancing resolver performance and maximizing privacy. For example, some resolvers operate extended TLS session lengths, which reduce protocol overheads and server processor loading but could lead to users leaving a bigger digital fingerprint.
• Separation of DoH and other HTTPS traffic – there has been some discussion whether DoH requests and normal content requests are handled separately in clients or whether they are multiplexed. If these are mixed, it is possible that cookies could be associated with the DoH requests, defeating attempts at user anonymity.

As these examples illustrate, it would be wrong to assume that the use of encrypted DNS automatically assures privacy of user data.

Standards for resolver operators

One initiative currently underway to provide users with assurance of the practices employed by resolver operators, including those supporting DoH, is the European DNS Resolver Policy. I developed this Policy, working with a range of organizations drawn from across the tech and telecoms industries in Europe and the US, complemented by representatives from civil society.

The initiative sets out policies relating to, for example, the handling of personal data, blocking of access to malicious content and sharing of cyber intelligence. It also sets an expectation that resolver operators should publish a transparency and privacy notice that outlines their operational practices. Further details will be available shortly.

More work still needed

It will be clear to anyone that has been looking at this area that a fair amount of progress has been made over the last 12 months or so. It should also be clear, however, that there is a considerable amount of work still to be done before the infrastructure using DoH is in a position to take on more than a tiny percentage of the traffic currently using the traditional Do53 protocol.

The lack of an interim SPAU solution for the nearly 400 million European Internet users is a particular worry, with user choice needing to be maintained while protecting data privacy. The privacy choices of both client software developers and resolver operators also require further evaluation and, quite possibly, additional direction.

These and other matters all need to be addressed if this key part of the Internet infrastructure is to remain as open, decentralized and resilient in the future as it has been to date.

_____

• This article was originally posted on the APNIC blog on 30 October.