discussion paper: dns over https - norbert pohlmann

Discussion Paper:DNS over HTTPSProduced by members of

eco – Association of the Internet Industry

ContributorsVittorio Bertola, Open-Xchange AGChristian Elmerot, Cloudflare Inc.Caroline Greer, Cloudflare Inc.Thomas Grob, Deutsche Telekom AGBert Hubert, Open-Xchange AG / PowerDNS.COM BVPatrick Ben Koetter, sys4 AGKlaus Landefeld, eco – Association of the Internet IndustryProf. Dr. Norbert Pohlmann, eco – Association of the Internet IndustryThomas Rickert, Rickert Rechtsanwaltsgesellschaft m.b.HCarsten Strotmann, sys4 AG

Project ManagementJudith Ellis, eco – Association of the Internet IndustryLars Steffen, eco – Association of the Internet Industry

DNS OVER HTTPS

DNS OVER HTTPS

Discussion Paper: DNS over HTTPS

Produced by members of eco – Association of the Internet Industry

This paper has been developed out of the collaboration of members of the eco Association who are all stakeholders in the ecosystem

of DNS provision. The initial intention of the paper was to provide a combined position on the DNS over HTTPS (DoH) protocol and

its various implementations. However, finding general consensus on all areas of discussion proved to be overly ambitious. As a result,

contributors have agreed to disagree on some topics, and participation in the development of this paper should not be construed as

endorsement of all sections and recommendations.

Where the participants are all in agreement is that the encryption of DNS services should be encouraged on a broad scale, in order to

increase the security and privacy of Internet users. The partial disagreement is on whether the deployment of encrypted DNS services

should be encouraged unconditionally, or only in specific situations and under certain policies.

Disclaimer:

Cloudflare has implemented DoH with the sole objective of ensuring strong privacy and security protections for users. Cloudflare is not in

agreement with some of the arguments (including of a technical nature) presented in the paper against third-party non-ISP DNS resolvers,

application and browser implementation, and believes that some of the positions taken do not objectively reflect the current situation.

DISCUSSION PAPER: DNS OVER HTTPS

3

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry

DNS OVER HTTPS DNS OVER HTTPS

Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. What is DoH and how does it differ from traditional DNS? . . . . . . . . . . . . . . . . . 52.1 Traditional DNS – the basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52.2 DNS over HTTPS (DoH) – the basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Excursion: What are DoT, TLS, and DNSSEC? . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

2.3.1 Mechanisms to secure DNS traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82.3.2 TLS handshake – establishing an encrypted session . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.3 SSL stripping – downgrading to unencrypted DNS . . . . . . . . . . . . . . . . . . . . . . . . 92.3.4 Why DoH?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92.3.5 DNSSEC – detecting forgeries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

2.4 DNS encryption, DNS privacy and Man-in-the-Middle attacks . . . . . . . . . . . . . . . . . . 102.4.1 DNS privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.2 Man-in-the-Middle (MITM) attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.3 Protection in untrusted environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. How does DoH interact with existing network environments? . . . . . . . . . . . . . 113.1 Public network – Wi-Fi hotspots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Home network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Corporate network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.4 Split horizon – different results in different applications . . . . . . . . . . . . . . . . . . . . . 11

4. Implementation / Operational Choices . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1 Implementation in system vs. application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Centralisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3 Privacy and tracking in DoH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3.1 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3.2 Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3.3 Giving users informed control over the DNS data . . . . . . . . . . . . . . . . . . . . . . 15

4.4 Data logging and the importance of privacy-enhancing techniques . . . . . . . . . . . . . . . 16

5. DNS Resolver Operator Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.1 Customer protection – logging for security purposes . . . . . . . . . . . . . . . . . . . . . . . 175.2 Network performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.2.1 Peering conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2.2 Rerouting to CDN caches – geographical filtering . . . . . . . . . . . . . . . . . . . . . . 18

5.3 Regulatory issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.4 Additional DNS-based services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6. User Level: User Choice and Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . 206.1 Technology should be implemented to ensure choice for users & admins . . . . . . . . . . . . 206.2 Choice of default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

7. To be standardised: Network discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 21

8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228.1 Risks to privacy and security of unencrypted DNS – Why and where DoH is a good idea . . . 228.2 Risks entailed in certain DoH implementation models . . . . . . . . . . . . . . . . . . . . . . . 22

8.2.1 Privacy & tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228.2.2 Default DoH at the application level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228.2.3 Centralisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8.3 Recommendations for implementing DoH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238.3.1 Deployment recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238.3.2 Legal recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238.3.3 Implementation recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Imprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25


4

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry

DNS OVER HTTPS

1. Introduction

Initial position: DNS Encryption is good!

With more than 1,100 member companies, eco is the largest asso-

ciation of the Internet industry in Europe, representing all sectors

from network infrastructure, Internet service providers (ISPs), con-

tent delivery networks (CDNs), service and application providers,

to cyber security and legal experts. A group of members have

taken the opportunity to make the most of this source of broad

and diverse expertise to discuss the emerging use of the DNS over

HTTPS (DoH) protocol and the impact of its implementation on

different environments.

It is probably safe to say that the introduction of the DoH protocol

has created more controversy than its initiators and early adopters

were anticipating.

One objective pursued in the development of the DoH protocol was

to increase user privacy and security by preventing eavesdropping

and manipulation of DNS data, e.g. by Man-in-the-Middle attacks

(MITM). Throughout the history of the Internet, traditional Domain

Name System (DNS) traffic has largely been unencrypted. In this

scenario, every party between the user’s device and the DNS

resolver is able to look into DNS queries and responses, or even

to modify them. Furthermore, the monetisation of DNS data, e.g.

for marketing purposes, is a potential and realistic privacy issue.

In the early phases of implementation, DoH was a topic of intense

discussion and considerable controversy. First-movers in this

space were largely not traditional network operators and ISPs –

who have until now been largely responsible for the provision of

DNS services – but rather application developers, content delivery

networks, and distributed DNS providers, in order to offer users

easy access to encrypted DNS and greater choice in the provision

of DNS services. Initiatives in this context have created a strong

impetus for other operators of DNS resolvers to also become active

in the provision of encrypted DNS services like DNS over HTTPS.

This offers the potential for the protocol to emerge out of a niche

status and become more widely deployed by all kinds of DNS pro-

viders, allowing it to make a significant contribution to the pro-

vision of encrypted DNS.

Encrypting DNS improves user privacy and security. This is why the

contributors to this paper strongly support the concept of provi-

sioning over-the-top encrypted DNS. As DoH is relatively new, it

is not yet universally deployed, and many ISP resolvers still lack

support. However, increasing adoption can be observed. This is to

be encouraged, in order to ensure a rich and varied global eco-

system of encrypted DNS provision.

Despite this, the sometimes-heated discussion around DoH has

highlighted a tangled range of questions and ambiguities. The aim

of this paper is to identify what needs to be teased out in order to

understand what stems from the protocol itself, and what relates

to possible implementation models and/or deployments of the DoH

protocol, and what action needs to be taken within the industry

to, on the one hand, ensure the protection of user privacy through

the DoH protocol, and on the other hand, ensure user choice and

digital self-determination.

This paper will attempt to unravel some complexities of the DoH

discussion, try to provide as neutral as possible an industry per-

spective on the pros and cons discussed in this context, and make

them comprehensible for readers for whom an understanding of

DoH is relevant. It makes recommendations for the deployment and

implementation of DoH in a privacy-enhancing manner.

As a first statement of positioning, the contributors to this paper fundamentally support the encryption of DNS information.

Encryption of DNS has the advantage of improving user privacy

and security, for example, by preventing malicious actors from

listening in to DNS traffic e.g. in order to perform Man-in-the-

Middle attacks.

However, the contributors also concede that there are contexts

where certain stakeholders – for example, operators of a corpo-

rate network, or Internet service providers – may have concerns

regarding potential downsides of certain implementations for

encrypting DNS information. The concerns generally do not relate

to the DoH protocol itself, but to the deployment model chosen

by the applications, especially web browsers.


5

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry


Why is this paper necessary?

Not only do the contributors to this paper take the position that

DNS encryption is good, they also take the viewpoint that the DNS

over HTTPS (DoH) protocol in itself is sound, as is the related pro-

tocol, DNS over TLS (DoT), the latter offering another method of

encrypting DNS traffic, but not being the primary focus of this paper.

DNS over HTTPS does, however, have a few residual issues. Here,

it is important to differentiate the level at which these concerns

reside: the protocol, the implementation, or third-party deployments.1

This paper aims to provide recommendations for DoH implemen-

tation and deployment that maximise the positive effects while

addressing the negative ones.

1 The contributors to this paper acknowledge the threat of DoH centralisation; this topic is covered specifically in Section 4.1, however is not in the focus of discussion in other sections.

2. What is DoH and how does it

differ from traditional DNS? 2.1 Traditional DNS – the basics

The Domain Name System basically functions as the telephone

book of the Internet. If we think of the Top-Level Domain (for

example, .com, .de, .org or .info, to name only a few) as equivalent

to the country code or area code, the second-level domain (in the

case of international.eco.de, this would be .eco) as the corporate

switchboard number, and the third-level domain (international) as

the specific extension, it is possible to get a picture of how this

directory is compiled, and how computers go about finding the

service that they want to visit.

In the first step of finding a service, the operating system of the

computer in use has the capacity to define how DNS will be pro-

cessed, and which DNS resolver should be used. The first DNS

resolver that the computer is locally connected to is the home or

office router, or a public hotspot.

DNS resolvers are responsible for finding the Internet resource (e.g.

a website) that a user has inputted into their computer. To do this,

they follow a series of steps, looking initially to see whether they

have, firstly, a preconfigured setting for this service, or secondly,

a record of previous visits to this website (this record is called a

cache). Failing this, the resolver will forward the DNS query to the

next resolver up, for example, the DNS resolver of the Internet

service provider (ISP) that the user is connected to (located in the

same geographical region as the user). This resolver will follow the

same steps – checking for a configured setting, checking the cache

for recently-requested or popular domains – and finally, if all else

fails, will proceed to looking the domain up in the “Internet tele-

phone book” via a process called “recursive resolution”.

In corporate networks, the selected resolver is typically controlled

by the network administrator, while in home networks the resolver

is usually provided and controlled by the ISP. If desired, users and

network administrators can override the resolver with a specific

address. However, outside of this environment, when connecting to

a public hotspot, most users are unlikely to change their settings.


6

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry

DNS OVER HTTPS

Fig. 1b Traditional DNS resolution from the local network resolver to the ISP to the destination

Known network resolver(home/o�ce router) OR

public hotspot

From this point onwards, DNS request is aggregated,therefore device/user not individually identifiable.

= Vulnerability (here: to MITM attacks)

Device XY (computer/smartphone/tablet)

Traditional DNS

User types URL:“international.eco.de”

System looks forinternational.eco.de

App asks system:international.eco.de?

1

2 System resolver asks network:international.eco.de?

4

3

System resolver(in operating

system)

SoftwareApplication

1. Locally configured settings? – e.g. CDN content caches or URL blocks

2. Checks cache – previous lookups to same domain?

3. If no to 1 & 2 above, then system resolver asks:

1. Locally configured settings? – e.g. CDN content caches or URL blocks

2. Checks cache – previous or regular lookups to same domain by other ISP customers?

3. If no to 1 & 2 above, then network resolver asks:

ISP resolverResolver sends queries out to name servers

for particular domains or root servers

= Vulnerability (here: to MITM attacks)

Local network

Known network resolver(home/o�ce router) OR

public hotspot

From this point onwards, DNS request is aggregated,therefore device/user not individually identifiable.

Traditional DNS

Network resolversearches for

international.eco.de

DNS request isaggregated,

therefore usernot individually

identifiable

(other server…)

(oth

er serv

er…)

go

og

le.c

om

ser

ver

.de servereco.de server

.com

server

Fig. 1a Traditional DNS resolution from the device to the local network resolver


7

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry


2.2 DNS over HTTPS (DoH) – the basics

The DNS over HTTPS protocol in itself only changes the transport

mechanism over which the user device and the resolver commu-

nicate. Rather than using the traditional DNS protocol, which is

unencrypted, the requests and the responses are encapsulated in

an encrypted web access transaction that uses the well-known

HTTPS protocol. As a result, the DNS resolution traffic gets mixed

with the rest of the user’s web access traffic.

Given that many applications – starting of course with web browsers

– are already capable of communicating through the HTTPS protocol,

the consequence is that applications can easily start to perform

their own DNS resolution, rather than relying on the functionality

provided by the operating system. This in itself creates a potential

issue, as applications can then direct their queries to a different

resolver than the one used by the operating system, and thus by

“traditional” DNS; and this resolver could sport differences in per-

formance (see Section 5.2), availability, or even in the responses

themselves (see Sections 3.4, 5.3 & 5.4).

Default application-selected DoH

One implementation of DoH (Scenario 1) in an application directs

the DNS queries, as a default, to DoH servers that have been spe-

cifically vetted by the application developer itself for their privacy

protection policies, and approved under the given developer’s

Trusted Recursive Resolver Policy (TRRP). As a consequence, the

user’s DNS queries, when using this application, will not be directed

to the resolver provided locally by the home or corporate network,

where the user's DNS queries by the other applications are going.

Application-based DoH

Device XY



system)Known networkresolver (home/

o�ce router) ORpublic hotspot

ISP resolver

DoH resolverResolver sends queries out to name servers

for particular domains or root servers

= Vulnerability (here: to tracking – device and app individually identifiable)

App goes directly to DoH resolver, bypassing system and network settings

App and device are recognisable by DoH resolverdue to lack of DNS request aggregation

DNS information is encrypted

(other server…)

(oth

er serv

er…)

go

og

le.c

om

ser

ver


.com

server

SoftwareApplication

Fig. 2 DNS resolution via DoH as implemented as default in an application


8

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry

DNS OVER HTTPS

Same provider auto-upgrade DoH

A different approach, called “same provider auto-upgrade DoH”

(Scenario 2), has also emerged more recently: In this case, the appli-

cation uses DoH by default only when it is possible to do so while

still using the operating system resolver. This approach resolves

many of the issues discussed below with regard to corporate net-

works and consumer Internet access. However, as a drawback, these

applications will only be able to use DoH when the system resolver

has been upgraded to also offer a DoH interface, a situation which

is currently not the norm. Additionally, there currently is no stan-

dard mechanism for the system resolver to signal the existence of a

DoH interface to it, and for the applications to look for this signal.

Efforts to solve this problem are currently ongoing at the IETF.

Whether or not it is in the best interests of the individual user to

have default third-party DoH resolution as described in Scenario

1 will depend on the context. In the first instance, this scenario

forces encrypted DNS, while in Scenario 2 the fall-back position

will be unencrypted DNS.

However, there is no guarantee that the approved DoH providers

in Scenario 1 will have a resolver in the local region of the user,

which may lead to network performance issues in some circum-

stances. Despite this objection, the reverse can also be the case:

depending on the quality of service of the local ISP, third-party

DNS resolution may offer better performance.

On the other hand, currently the number of DoH providers that have

chosen to implement the practices set out by the TRRP and/or been

approved by application vendors remains limited. This presents a

potential risk to the open and distributed nature of the Internet in

terms of centralisation of an essential Internet resource, unless the

number of operators providing DoH grows significantly.

Regardless of the implementation scenario, a mechanism for net-

work discovery is still needed, in order for DoH resolvers to be

recognised by applications, because manual vetting of providers

cannot effectively scale to a truly rich, varied and distributed

ecosystem at a global level. Furthermore, users need to be fully

informed of where their DNS requests are going and be given the

opportunity to choose the operator through which they wish their

DNS requests to be processed.

Oblivious DoH

A third approach, Oblivious DoH, (Scenario 3) requires changes both

in implementation and in deployment and is a new evolution of DoH

designed to eliminate the risk of tracking of user behaviour. Here,

proxying allows the client IP addresses to be hidden, and there is a

separation between the server receiving the DoH request and the

server sending the response. This improves privacy of DNS oper-

ations by not allowing any one server entity to be aware of both

the client IP address and the content of DNS queries and answers.2

This scenario is expected to be deployed for the first time in late

2020, with options for implementation both in applications and

at the level of the operating system.

Adaptive DoH

A fourth approach (Scenario 4) named “Adaptive DoH” has been

recently proposed at the IETF. In this approach, the concept of a

single DoH resolver for all the user’s queries would disappear, and

each query would be directed to a different resolver designated by

each destination domain. In practice, applications would send all

queries for Google domains to Google’s DoH resolver, all queries

for Facebook domains to Facebook’s DoH resolver and so on. This

scenario may prompt several additional technical and policy con-

cerns, but since it has not been deployed or standardised yet, we

chose not to analyse it for the time being; we rather recommend

that proper analysis and a discussion on the best deployment con-

ditions is accomplished before standardising it and deploying it in

consumer applications.

2.3 Excursion: What are DoT, TLS, and DNSSEC?3

2.3.1 Mechanisms to secure DNS trafficWhen DoH is being discussed, the topics of DoT and TLS often arise.

Two standardised mechanisms exist to secure the DNS traffic between

the user and the resolver, DNS over TLS (DoT) and DNS over HTTPS.

Both are based on Transport Layer Security (TLS), which is also used

to secure communication between the user and a website using

HTTPS. In TLS, the web server or DNS resolver authenticates itself

to the user’s client using a certificate. This ensures that no other

party can impersonate the web server or DNS resolver.

2 https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh-003 Much of the background information in Section 2.3 has been adapted from https://blog.

cloudflare.com/dns-encryption-explained/

https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh-00

https://blog.cloudflare.com/dns-encryption-explained/

https://blog.cloudflare.com/dns-encryption-explained/


9

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry


There are two methods to enable DoT or DoH on end-user devices:

1. Add support to applications, bypassing the resolver settings from

the operating system.

2. Add support to the operating system, transparently providing

support to applications.

There are usually three configuration modes for DoT or DoH on

the client side:

• Off: DNS will not be encrypted.

• Opportunistic mode: try to use secure transport for DNS, but

fall back to unencrypted DNS if the former is unavailable. This

mode is vulnerable to downgrade attacks, where an attacker can

force a device to use unencrypted DNS. It aims to offer privacy

when there are no on-path active attackers.

• Strict mode: try to use DNS over secure transport. If unavailable,

fail hard and show an error to the user.

With DNS over TLS (DoT), the original DNS query is directly embedded

into the secure TLS channel. From the outside, no one can learn

the name that was being queried or modify it.

2.3.2 TLS handshake – establishing an encrypted sessionIn the packet trace for unencrypted DNS, it is clear that a DNS

request can be sent directly by the client, followed by a DNS answer

from the resolver. In the encrypted DoT case, however, what are

known as “TLS handshake messages” are exchanged prior to sending

encrypted DNS messages:

1. The client sends a “Client Hello”, advertising its supported TLS

capabilities.

2. The server responds with a “Server Hello”, agreeing on TLS param-

eters that will be used to secure the connection. The Certificate

message contains the identity of the server while the Certificate

Verify message contains a digital signature which can be veri-

fied by the client using the server certificate. The client typically

checks this certificate against its local list of trusted Certificate

Authorities, but the DoT specification mentions alternative trust

mechanisms such as public key pinning.

3. Once the TLS handshake is finished by both the client and server,

they can finally start exchanging encrypted messages.

4. While the above picture contains one DNS query and answer, in

practice the secure TLS connection will remain open and will be

reused for future DNS queries.

2.3.3 SSL stripping – downgrading to unencrypted DNSSecuring unencrypted protocols by adding TLS on top of a new port

has been done before. A problem with introducing a new port is

that existing firewalls may block it, either because they employ an

approval process where new services have to be explicitly enabled,

or a blocklist approach where a network administrator explicitly

blocks a service. If the secure option (DoT) is less likely to be avail-

able than its insecure option, then users and applications might be

tempted to try to fall back to unencrypted DNS. This subsequently

could allow attackers to force users to an insecure version. Such

fallback attacks are not theoretical. SSL stripping has previously

been used to downgrade HTTPS websites to HTTP, allowing attackers

to steal passwords or hijack accounts.

2.3.4 Why DoH?The approach on which this paper is focusing, DNS over HTTPS

(DoH), was designed to support two primary use cases:

1. Prevent any interference with DNS by on-path devices and

networks. This includes the scenario of port blocking described

above, but also any other DNS-based monitoring, security and

control mechanisms, both legitimate and adversarial.

2. Enable web applications to access DNS through existing browser

APIs. DoH is essentially HTTPS, the same encrypted standard

the web uses, and reuses the same port number (tcp/443). Web

browsers have already deprecated non-secure HTTP in favour

of HTTPS. That makes HTTPS an appealing choice for securely

transporting DNS traffic.

2.3.5 DNSSEC – detecting forgeriesThe Domain Name System Security Extensions (DNSSEC)4 secure the

DNS by adding cryptographic signatures to existing DNS records. By

checking its associated signature, it can be verified that a requested

DNS record comes from its authoritative name server and has not

been manipulated. Whereas the HTTPS in DoH and DoT encrypts the

traffic so no third party can spy on users’ Internet traffic, DNSSEC

signs responses, making forgeries detectable.

DoH and DoT only ensure that a user receives the untampered answer

from the DNS resolver. They do not, however, protect the user against

the resolver returning the wrong answer (through DNS hijacking

or DNS cache poisoning attacks). The “true” answer is determined

by the owner of a domain or zone as reported by the authorita-

tive name server. DNSSEC allows clients to verify the integrity of

4 The contributors to this paper strongly advocate the use of DNSSEC as a security enhancement for the communication of DNS information. However, in the current implementation landscape of DNSSEC (in which it is implemented on a low proportion of DNS resolvers), the contributors also acknowledge that a great deal of DNS information remains vulnerable.


10

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry

DNS OVER HTTPS

2.4.2 Man-in-the-Middle (MITM) attacksThe encryption of DNS traffic protects the user from the potential

that a malicious actor is able to listen in to the user’s DNS requests,

and is subsequently able to redirect the user to a different (mali-

cious) destination – for example, a fake bank website instead of

the real one the user wanted to go to. This kind of cyber attack

is known as a Man-in-the-Middle (MITM) attack. Encrypted DNS

through DoH/DoT are the only realistic solutions available today.6

2.4.3 Protection in untrusted environmentsTherefore, when it comes to the choice to use DoH in different

network environments, the biggest difference is one of trust. DoH

offers an opportunity to protect communications in an untrusted

environment. However, DoH may not be the preferred option for

trusted network environments, such as corporate networks or

Internet access services acquired from an ISP that the user trusts.

DoH also only addresses the problem of an attack from the net-

work. It does not address the problem of an attack coming from

the resolver itself, for example through abuse of the personal

information included within the user’s DNS queries. Whether the

user trusts the network operator less or more than the DNS/DoH

resolver operator, at least when the two differ, is a key element

for determining which deployment model provides better protec-

tion to the user.

6 It should be noted that the risk of MITM attacks cannot be eliminated with the Domain Name System Security Extensions (DNSSEC). MITM attacks are started by attacking the DNS betweem a DNS client and a DNS resolver, whereas DNSSEC is currently only deployed between DNS resolver and authoritative DNS server, not between DNS client and DNS resolver. While it would be possible to secure DNS with DNSSEC between DNS client and DNS resolver, no operating system vendor (except OpenBSD) or browser developer has implemented DNSSEC on the client side. While DNSSEC verifies the authenticity of DNS responses, it does not protect against attackers blocking DNS queries/answers that it does not like. Although DNSSEC is certainly a mechanism for increasing trust in the Internet by ensuring that communications received are valid, it is unfortunately currently not widely deployed.

the returned DNS answer and catch any unauthorised tampering

along the path between the client and authoritative name server.

2.4 DNS encryption, DNS privacy and Man-in-the-Middle attacks

With the rise of smart mobile phones and tablets, a share of Internet

usage happens away from home. To save on mobile data caps, often

these devices connect to different public wireless (Wi-Fi) networks

supplied by hotels and restaurants or by local public administrations.

2.4.1 DNS privacyThe DNS query data issued from mobile devices in wireless net-

works (in hotels, coffee shops, hospitals, shopping malls, etc.) may

be used to analyse customer behaviour and to track customers

across networks. Often these DNS services are part of an all-in-one

Wi-Fi solution sold to different markets worldwide.5 Some of these

solutions are poorly adapted to comply with local privacy laws, or

the privacy protecting configurations are not enabled.

Free public Wi-Fi services, especially when operated or provided

by smaller businesses, are often poorly managed in terms of secu-

rity and performance. DoH protects the user in these public wire-

less networks, as the DNS resolver of the Wi-Fi network is being

bypassed, preventing user tracking at this level. In these scenarios

DoH can increase both the privacy and the performance of the DNS

service for the end user.

5 https://www.hotelwifi.pro/ | https://hospitalitytech.com/WiFi-analytics-unlock-new-opportunities-hoteliers | https://spotonwifi.com/hospitality-wifi-wifi-marketing-analytics/


11

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry


3. How does DoH interact with existing network

environments?

3.1 Public network – Wi-Fi hotspots

If a user is in a public hotspot and does not know anything about

the network – which is the norm today in environments like cafes,

restaurants, and hotels, etc. – then this network is completely

untrusted. In this scenario, the user cannot trust the authenticity

of what they are seeing, has no idea whether someone in the net-

work might be wanting to access and/or store information being

transmitted over the network, and is vulnerable to Man-in-the-

Middle attacks. The highest risk of a user being exposed in this

way is within such open public networks.

Therefore, examining the question of whether it makes sense to

use a DoH resolver in preference to the resolver provided by the

network, the most conducive place for the use of DoH would actu-

ally be a public network.

3.2 Home network

In a home network, by contrast, typically one would argue that it

makes absolute sense for the home router to override DNS reso-

lution. For example, this is how parental control – which disallows

access for minors to non-age-appropriate sites – can function. As

this is the home router, controlled by the user, the user is more

likely to be able to trust this device.

The next step in DNS resolution – the ISP’s resolver – may also be

seen as trusted by the user, a customer of the given ISP. However,

in the case that the user does not trust their ISP and has no viable

alternative for Internet access, the home network may also be a

context in which DoH can provide a valuable privacy enhancement

if properly implemented.

Furthermore, even in the case that the user does trust their ISP, there

may still be value in encrypting the DNS connection, to prevent

possible eavesdropping by any attackers on the ISP’s network. In

this case, however, the onus should be on the ISP to upgrade their

resolver so that it also supports DoH, and the user device should

continue using the network’s resolver, only through DoH instead of

the original DNS protocol. Furthermore, in this case, applications

should detect the existence of a DoH interface to the ISP resolver

and use it automatically.

3.3 Corporate network

In the corporate environment, the trust context becomes even

clearer. The user would typically trust this network and also trust

the resolver as part of it. Therefore, it does not make sense from a

trust perspective to override the corporate resolver by using DoH

and within a corporate environment, an organisation may have

legitimate reasons to disallow this.

Furthermore, in terms of corporate IT rules, any application that

ignores the system default and overrides it by default would not

be desirable within a corporate network – and may even be con-

sidered potentially harmful, because the network administrator is

unable to control it within the network. It is highly likely that such

an application found in a corporate environment would be banned

outright from that environment. However, this certainly becomes

more difficult with a general-purpose application like a browser.

3.4 Split horizon – different results in different applications

Enabling an application – most specifically, a browser – to override

the system resolver means that different applications may be using

different resolvers to reach the same destination on the one device,

and be retrieving different results. This issue is known as a “split

horizon”. In the case of an application using default third-party

DoH for DNS resolution, a new situation arises which is analogous

to the split horizon scenario, but is not desirable on corporate IT

devices. On the one hand, different applications (e.g. two different

browsers) on the same device would provide different responses.

Secondly, in this scenario the user (company employee) accessing

the site via an external DoH resolver would not be able to access

company-internal resources.


12

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry

DNS OVER HTTPS

This is because, within a corporate network, some split horizon

scenarios are actually desired – in this way, the network oper-

ator can protect company resources by only allowing them to be

accessed from within the network, e.g. a corporate intranet. The

split horizon means that users outside of the network who try to

access the corporate website, for example, will be directed to the

public site, whereas users within the network would be directed

to the log-in page to gain access to the back-end.



system)

SoftwareApplication


system) Corporatenetworkresolver

(o�ce router)

Company Network Environment and Split Horizon

1. Local resolution – access to company resources (e.g. log-in for website backend)

Corporate networkresolver

(o�ce router)

Device XY using Traditional DNS

Local network

App asks system:international.eco.de?

Website response:Access to IntranetUsername:Password:

Website response:Public websiteLatest news …Join us at event XY …

Device XY using DoH

DoH resolver

Resolver sends queries out toname servers for particular

domains or root servers

= Vulnerability (here: to tracking – device and app individually identifiable)


SoftwareApplication

(other server…)

(oth

er serv

er…)

go

og

le.c

om

ser

ver


.com

server

Fig. 3 Traditional DNS resolution vs. DoH resolution in a corporate network – the Split Horizon

The use of an application with default third-party DoH within a

corporate network in this scenario would mean that the user is

actually accessing the site via an external resolver, thus resulting in

the employee not being able to access company-internal resources.


13

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry


4.1 Implementation in system vs. application

Many of the concerns relating to corporate networks cease to

be concerns if DoH is implemented on a system level rather than

the application level (such as in a browser). At the system level,

system policies are easier to handle: there are already provisions

to enable the use of different DNS resolvers depending on which

network the device is on. For example, the system can be config-

ured to select a specific non-local DNS resolver to override a public

network resolver, but the moment the device is connected to the

office network, it will use the corporate network DNS resolver, and

likewise for the home network.

Furthermore, the system policies on a corporate device, for example,

could prevent the user from changing to an external resolver and

could force local DNS while the device is in the corporate network.

In this implementation, a lot of corporate network administrators

are likely to create a corresponding policy: as long as the device is

on the corporate network, the corporate resolver should be used,

but the moment the device is on a public network, DoH should be

used, because it is considerably more secure than allowing a public

hotspot to do the resolution.

However, if DoH is implemented as default on the application level,

these different configurations, which are activated depending on

where the device is, are circumvented. Instead, the device will always

use DoH, with all of the issues that this entails for the corporate

network. Implementing DoH at the system level is not only possible

but has already been done on Unix and Android, and work is being

undertaken currently to implement DoH in other major operating

systems. This then allows the user to change the system resolver to

use DoH. If implemented in this way, an application-based approach

would no longer be necessary.

Recommendation:

DoH on the application level should not be a default setting. DoH would be better implemented on the OS level.

4. Implementation / Operational Choices

4.2 Centralisation

Provider centralisation – in combination with the possible tracking

capabilities of DoH (see Section 4.3.2) – entails the risk of data

collection points where data regarding user behaviour would be

aggregated on a global scale. In the current implementation cli-

mate that has seen the misuse of user data and privacy violations,

such centralisation can be a concern.

Centralised DoH resolver providers could be very well intentioned

and believe deeply in providing a neutral, reliable encrypted ser-

vice, without gaining any benefit from the potential control such

a centralised position offers. There is, however, understandable

worry about commercial operators routing significant parts of

Internet control through their networks. Centralised operators

can counter such worries with privacy-focused user agreements

and public-facing audits.

Concerns relating to centralised DoH services that are identified

in this paper are in existence at the time of writing but they will

cease to be significant issues if the DNS resolution marketplace

changes and expands: a greater number of operators offering DoH

resolvers, more widely dispersed and deployed, will provide more

choice for the user.

Whether this will remain a concern for the short or long term will

not only depend on the number of separate network providers that

choose to deploy DoH resolvers, but also on the model of imple-

mentation of network discovery into the applications supporting

DoH. With increasing uptake, the privacy and dependency risks

associated with centralisation of a major Internet resource will

diminish over time. It should be noted, however, that deployment

of DoH by providers of widely-used and popular applications may

result in the immediate materialisation of this risk.


14

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry

DNS OVER HTTPS

4.3 Privacy and tracking in DoH

4.3.1 PrivacyThere is considerable discussion of the privacy impact of a wide-

spread adoption of DoH. Encrypting the connection between the

application and the resolver prevents unauthorised interception

and tracking of the user’s DNS queries, with a positive effect on

privacy; however, DoH could also allow for the collection of data

that enables individual devices to be tracked, and for this data to

be collected and stored (logged) and otherwise processed. While

this issue is not restricted to the DoH protocol, in combination with

the risk of centralisation of DNS provision through DoH (see Sec-

tion 4.2), it has the potential to have a significant negative impact

on user privacy. Greater uptake of DoH resolution throughout the

ecosystem in combination with the development of a network dis-

covery mechanism will mitigate this risk.

When applications direct DoH queries to a different resolver than

the one originally configured in the system, there could be a positive

or negative effect on privacy. This will depend firstly, on whether

the operator of the alternative resolver has adopted better or worse

data processing and privacy practices than the original one. Sec-

ondly, whether or not the user has provided informed consent to

the sharing of personal information with an additional DNS oper-

ator is of importance to understanding the impact. Thirdly, in some

circumstances, the legal framework that the resolver operator is

subject to may also be relevant to the user in terms of privacy and

data protection law.

When it comes to traditional DNS, it is firstly worth noting that

most name servers in Europe undertake no logging. In the European

regulatory environment, the operator of the first DNS resolver – the

provider – is not legally permitted to store and process any data that

could be construed as personal data (e.g. IP addresses), except for

network security and performance monitoring (though in this case

the data could be anonymised or at least pseudonymised). Therefore,

logging is in itself clearly not necessary to provide a DNS service.

Secondly, from a technical point of view, it is important to note

that traditional DNS is aggregated at the device and then at the

local network level – per household, office, or network. Within each

device, the operating system aggregates the DNS queries made

by all applications. Within any local network, typically the local

(home/corporate) router receives all DNS requests, and sends the

aggregated requests on to the ISP. Furthermore, leaving DNS traffic

unaggregated may well lead to an increased load on the resolvers,

which is not desirable. For the ISP, DNS traffic of the entire network

(e.g. a company network) is visible, which means information can

be gleaned about the entire network, but not about the individual

users within it.

4.3.2 TrackingOn the other hand, the DoH protocol, based on HTTPS, offers imme-

diate possibilities to track users through the existing mechanisms

that were developed for the web (e.g. cookies, device fingerprinting,

etc.). Furthermore, DoH connections occur at the level of the device

and even of the application, meaning at the level of the user, given

that users log in on certain applications and are therefore individ-

ually identifiable. DNS over HTTPS thus provides a channel directly

from an application to the designated DoH resolver, so that it is

possible for the operator of the resolver to isolate the DNS queries

for one specific device or even one specific application. This kind

of tracking is not possible with traditional DNS.

However, just because the DoH protocol makes such tracking possible

does not mean that DoH is necessarily implemented to undertake

such tracking. Developers and operators of current implementations

argue that such tracking is not carried out, making use of e.g. a

minimum user-agent header to improve privacy. Nonetheless, the

protocol itself leaves the way open for other implementations in

future which may not place such emphasis on user privacy.

Concerns have already previously been raised that the use of HTTPS

could weaken privacy due to the potential use of cookies for tracking

purposes. The DoH protocol designers considered various privacy

aspects and explicitly discourage use of HTTP cookies to prevent

tracking, a recommendation that is widely respected. However,

other HTTPS tracking mechanisms such as device fingerprinting

can be applied within the DoH server and it is impossible to detect

whether this is being done.

In addition to this, DoH tracking can be described as “sticky” – if

the device is taken from one network to another, the TLS session

ticket (which is used to improve performance when resuming con-

nections) makes the device identifiable on the new network as well,

and tracking can be continued. TLS session resumption improves

TLS 1.2 handshake performance, but can potentially be used to

correlate TLS connections. Luckily, use of TLS 1.3 obviates the need


15

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry


for TLS session resumption by reducing the number of round trips

by default, effectively addressing its associated privacy concern.

However, continued use of TLS 1.2 gives the operator of the resolver

the power to analyse behaviour and preferences of each user and

to undertake the profiling of individual users.

With this in mind, it should be noted that there is a clear differ-

ence between generating and logging tracking data, and setting

out contractually that this data is not being used, and ensuring

that the tracking data is not generated in the first place. This is not

simply a question of better or worse practice; in certain regions

this is required by law. In Europe at least, whenever personal data

is collected or otherwise processed, users need to be informed

about the processing according to Art. 12-14 General Data Pro-

tection Regulation (GDPR) before the data is collected or – if not

obtained from the data subject – within a reasonable period after

having obtained the personal data, but at the latest within one

month. Additionally, there needs to be a legal basis for the pro-

cessing of personal data.7

In sum, if logging is done, then additional legal measures need to be

taken to make it legally compliant with data protection and privacy

laws for the jurisdiction in which the user is accessing the service.

However, even outside of the European context, the privacy and

data protection practices encouraged by the GDPR can represent

best practice for providers anywhere in the world.

Given that tracking can be done on a per-endpoint basis, it is also

possible to analyse which websites are being used from which

geographical locations at what time of the day, for example. This

also theoretically offers the operator of the DoH resolver signifi-

cant market intelligence. Optimising advertising according to such

statistics would represent a massively profitable abuse of infor-

mation which the user has (potentially) not consented to make

available. Furthermore, it would mean that advertising could be

targeted exactly and specifically at individual users. In Europe,

without informed user consent to such tracking, this is unlikely to

represent an acceptable business model.

7 In this case, this could be performance of the contract or where the processing is necessary for the purposes of the legitimate interests pursued by the controller or a third party, see Art. 6 I (b) and (f) GDPR for more details. Where such legal basis cannot be established, the only other option that seems to be applicable would be a processing based on consent, see Art. 6 I (a) GDPR. The issue with this is that consent-based processing is tied to several requirements, see Art. 7 GDPR, e.g. it must be freely given and can be withdrawn at any time. The implications of that are quite far-reaching and seem to be difficult to fulfil. Therefore, if at all possible, all processing should be based on Art. 6 I (b) and (f) GDPR.

4.3.3 Giving users informed control over the DNS dataHowever, one key message that the contributors wish to convey is

that although DoH was initially conceived with a view to enhancing

user privacy, steps need to be taken by the providers of DoH and

by application developers implementing DoH in order to safeguard

these privacy enhancements.

Moreover, when considering the user’s online activities as a whole,

there are other protocol elements outside of DNS/DoH that can be

used by an attacker to identify the type of activity and acquire the

list of visited hosts; for example, the Server Name Indication (SNI)

while establishing the TLS connection, or the IP addresses that are

being contacted, or the overall pattern and shape of the traffic, or

any cleartext communication in subsequently-used protocols; so

it must be made clear to users that DoH, while fixing one possible

attack surface, does not in itself make online activities anonymous

and impossible to track, not even to the same level as a Virtual

Private Network (VPN) does.

This means that users should be educated, informed and given con-

trol, and should make their own choices over which entity should

receive their queries and through which protocol; and that DNS

operators providing DoH resolver services should be transparent

regarding how they use the protocol, and commit to privacy-friendly

practices that forbid the use of the tracking capabilities that are

possible as a result of the underlying HTTPS protocol.

Therefore, in discussing the risks and opportunities associated

with DoH, two aspects need to be differentiated: One is what is

the protocol is capable of, and the other is how it is being imple-

mented and offered as a service.


16

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry

DNS OVER HTTPS

Recommendation:

DoH implementations should ensure that user tracking is not possible, which can be achieved by controlling the usage of web cookies, device fingerprinting, TLS resumption tickets and other techniques that could be used for tracking.

DoH operators and application developers should disable these

features unless they are clearly necessary for other functional-

ities (authentication, performance), and in that case they should

explain this to the users and obtain their consent. DoH operators

and application developers should also release privacy policies

that document if and how they use these features of the protocol.

Additionally, it would be advisable for DoH operators and appli-

cation developers to work together on an implementation that

safeguards privacy.

Finally, in line with the requirements of European privacy laws,

users should always be given clear information and a choice

over which operator will receive their DNS queries and through

which protocol.

4.4 Data logging and the importance of privacy-enhancing techniques

The potential for the mis-use/abuse of DNS data by providers

within the ecosystem must always be considered. In the worst-

case scenario, one or a few centralised DoH providers could end

up with large pools of data regarding the behaviour of individual

(identifiable) Internet users. Even if the providers themselves were

clear that exploiting this data was not a business strategy and they

employed appropriate safeguards, any large data pool would also

potentially be an attractive target for malicious actors.

Data minimisation should therefore be followed as a best practice,

which would mitigate the risks identified above. There may be a

good reason to monitor network activity and keep logs for a lim-

ited period of time (for example, filtering for malicious activity on

the network – see Section 5.1), but providers need to make sure

that they are not logging more than necessary. For example, if the

provider is able to do the very specific analysis needed with just

one in 10,000 queries, then only one in 10,000 queries should be

logged and used for that purpose.

Where operators exceed these recommendations in terms of data

collection and storage, they need to make sure that they do it in a

compliant fashion. In a European context and as regards the pro-

cessing of personal data, compliant fashion means the need to have

a legal basis for all processing, including the fulfilment of Article

12-14 GDPR information duties towards the users and specifying

the retention period for the data. In the first place, providers need

to inform users that such logging is occurring, and then also to

be clear about what they are logging, for what period of time, and

what happens to the data.

Recommendation:

Privacy-enhancing technology and techniques are encouraged at all times, to complement encryption. This includes regarding the handling of logging data.

State-of-the-art technology and techniques such as privacy-by-

design, data minimisation and data anonymisation are encouraged

by the EU General Data Protection Regulation (GDPR) – which

can represent a best practice for privacy – when it comes to the

processing of personal data, and should be deployed when pos-

sible. Operators of DoH resolvers should follow data minimisa-

tion principles, including with regard to logging data. If there is

a good justification for keeping any part of the logs, this needs

to be explained clearly and unambiguously.


17

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry


There are a few core competencies that network operators tend to

want to maintain themselves – and DNS is generally one of these.

ISPs and network operators have a range of concerns about the

impact of default third-party DoH on the provision of their ser-

vices to customers. These can be broken down into: security and

customer protection, network performance, and regulatory issues,

which will each be dealt with separately below.

5.1 Customer protection – logging for security purposes

Many ISPs want to enable query logging to some extent. This is

especially important for ascertaining when a query goes to a mal-

ware site, for example. In this situation, the ISP can take action

and contact the customer to inform them that there is a problem

on their network that needs to be dealt with. This is the field of

customer protection and customer security, a new market for ISPs,

and ISPs are very interested to be working within that market to

keep their neighbourhood clean.

Research undertaken in 2015 among members of the eco Associ-

ation Anti-Abuse Working Group demonstrated that, on average,

10 percent of the traffic on the networks involved was caused by

malware from customers. This implies that 10 percent of what net-

work operators spend every year on hardware and infrastructure

is being used for malware running on their customers’ computers.

Network providers stand to lose out if they are unable to provide

DNS resolution, because their capacity to filter traffic for malware

analysis will be massively undermined. If all the DNS address traffic

goes off the platform (for example, in the case of a default third-

party approach), ISPs and network operators will be blind to traffic

activity on their network and they will be unable to counteract mali-

cious activity of this kind. This is also a concern for the operators

of government platforms and corporate networks.

Furthermore, ISPs have a vital interest in keeping their customer

turnover low. In the first instance, providing a high-quality service

is important to achieving this, and ISPs are wary of third parties

removing their control over parts of this service provision (see

Section 5.2). However, another new approach for ISPs to maintain

customer loyalty is to deal with customers’ security issues and help

keep customers safe and secure on the Internet. In this context,

if network abuse personnel are unable to see what is occurring in

their network, they are also unable to improve the overall security

of their network and keep customers happy in this way. Therefore,

it is essential to their operations and business model that they are

able to see the traffic.

The moment that DNS queries are being processed by a third-party

DNS resolver, the network operator will not be able to know what the

users are querying – information that the network operators need

in order to battle malware. In this case, it would be necessary to

have a service provider that feeds back to the network information

about what users are querying for. Here, network operators may end

up in the curious situation that they would need to approach the

DoH provider to request data about what is going on in their own

network. Potentially, the DoH provider could take the standpoint

that this data is a commodity on which they can base new at-cost

services – selling back to the operator a list of infected IP addresses.

This would mean, in turn, that network operators are suddenly and

unwillingly outsourcing a service that they are actually interested

in performing themselves, resulting in increased cost in order to

provide an essential service to their customers.

5.2 Network performance

The DNS has traditionally been something that the network service

provider or ISP is responsible for. Customers also perceive Internet

access in these terms, and if they use the Internet and the DNS is

slow, customers are not aware of what is at fault. If DNS is now

provided by an external third party (non-local) provider and there

are performance issues, then the Internet service provider is likely

still to be blamed by the customer.

5.2.1 Peering conflictsIf an ISP has a peering conflict with a third-party DoH provider,

this may also result in performance problems for either party, e.g.

connectivity issues. In a traditional setting, this would only impact

certain websites served by the given DNS provider, but in a DoH

scenario it will impact the performance of the Internet as a whole

for that ISP.

This is one significant reason for some of the controversy surrounding

DoH – an external third-party is now involved in the performance

of an ISP. Therefore, the authors of this paper are adamant that

any DoH provider arguing that they should be a default should also

commit to work together with Internet service providers to assure

service performance and establish direct interconnection for the

DNS look-up service with the ISP to eliminate third-party influence

from commercial negotiations.

5. DNS Resolver Operator Perspective


18

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry

DNS OVER HTTPS

5.2.2 Rerouting to CDN caches – geographical filteringMany of the largest Internet service providers have nodes of con-

tent delivery networks (CDNs) from the large content providers in

their own network. Given that network distance from a node can

impact the latency and thereby the quality of the service provision

of the content, DNS is used by some services as one way to route

consumers to the closest node within the ISP’s network. DNS plays,

for these services, an important role in the provision of high defi-

nition broadcasting, and video and audio streaming, for example.

Some major DoH providers argue that this distribution model,

when the information is sent to a third party in unencrypted form,

would be a privacy violation. While a point of contention, it does

provide additional challenges for ISPs trying to provide nodes for

CDN services within their network.

Recommendation:

If ISPs were to offer DoH alongside regular DNS, then the DNS-based geographical filtering for CDN-caching distribution can work without sacrificing privacy.

If all ISPs offered their own DoH, users would not have to switch

DNS providers to get encrypted DNS, and the ISP would still have

the ability to direct users to a closer destination.

If providers of authoritative DNS services deploy encrypted DNS, then disclosing the network location of the user would not be a privacy issue.

This would allow the authoritative DNS service to provide the

closest service node in the response sent to the user.

5.3 Regulatory issues

Currently, local courts from many countries can demand the blocking

of certain domains – on the basis either that it is displaying, for

example, child sexual abuse material (CSAM), or it is enabling illegal

streaming, gambling, or access to other content that is contrary to

legal requirements in that jurisdiction. A service provider is then

required to implement this block.

Jurisdictions in Europe generally do not mandate the specific tech-

nical mechanism to be used, but when the block is mandated by

domain name, blocking the resolution of the domain name in the

ISP’s resolver is the quickest and cheapest method. The block will

still be circumventable by smarter users, as they just need to use a

resolver in a different jurisdiction, but for most “average” Internet

users, DNS-based blocking is effective. This strikes a reasonable

balance between the need to deter access to illegal and harmful

content and the desire not to establish the invasive “censorship”

architectures used in some authoritarian regimes.

In the DoH scenario, the ISP is only able to block the DNS request

going to the ISP’s own resolvers. In the situation that a DoH-based

application bypasses the ISP resolver and goes to an external,

third-party resolver in a different jurisdiction in order to access

the Internet, the user is able to circumvent the legally-mandated

block by using DoH. As a consequence, the service provider could

be held responsible for the lack of blocking efficiency and is likely

to be required to implement more extensive and more intrusive

measures (e.g. deep packet inspection, IP address blocking).

However, if an ISP has set up its own DoH resolver, and this resolver

is the first choice for the network’s customers, then the provider

can still ensure that legally-mandated blocking is effective by also

implementing the block in the DoH resolver. As a result, DoH does

not per se undermine locally-mandated blocking, as long as there

are DoH resolvers within the jurisdiction and these resolvers are

being used by clients within that jurisdiction.

Furthermore, if clients adopt a “same provider” approach to DoH

deployment, sending the encrypted queries to a DoH resolver run

by the same operator as provides the traditional DNS resolver con-

figured in the operating system, then the jurisdiction will be the

same and no circumvention of local regulations will take place.

This, however, requires that all ISPs that currently offer an unen-

crypted DNS resolver also offer an encrypted DoH one, and that

proper discovery mechanisms (see Section 7) are developed and

deployed to allow the “same provider” upgrade to encrypted DNS

for the clients that choose to adopt that model.

Implementing a DoH resolver in parallel to an existing DNS resolver

is not a significant burden in terms of costs for ISPs and network

operators. There is little practical difficulty implementing it from a

technical perspective. It will be another thing to inform customers

about the process and the offer, but this should also be manage-

able and not involve large costs.


19

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry


Recommendation:

Networks should be encouraged to implement their own DoH resolver.

The recommendation would be that if Internet service providers

want to keep their own DNS – for purposes of having visibility

for malware filtering, or maintaining control over routing – they

should make sure that it is performant, and that they comply

with local legal requirements.

The performance of the Internet as accessed over DoH – as well

as compliance with local laws – will be improved through the

wide-scale deployment and uptake of DoH resolution services

offered by ISPs and network operators.

Clients should either choose the “same provider” DoH deployment

model, adopting appropriate technical mechanisms to discover

the DoH equivalent to the currently configured DNS resolver,

or make sure that the legal implications of a possible change

of jurisdiction in DNS resolution are understood and addressed.

5.4 Additional DNS-based services

Some DNS resolver operators – both ISPs and enterprises that pro-

vide the resolver as part of an Internet access service, and global

open resolver operators – provide additional value-added services

on top of their resolver, either by default for all their users or on

demand for a specific subset, either for free, as part of a larger

paid product (e.g. Internet access), or as an additional paid option

that customers can buy separately.

Typical services of this kind are parental control (blocking websites

unsuitable for children), productivity control (blocking websites

inappropriate or disallowed on the workplace, like social media),

and security filtering.

These services are sometimes acquired by the owner of the device,

but they are more often acquired by the owner of the local network

(enterprise, home) and imposed on any person using that network

(employees, young family members).

To work, these services require that all applications on the customer’s

device use that specific resolver for resolution. It does not matter if

the resolver is accessed via unencrypted DNS, DoT or DoH, as long

as the operator provides the filtering engine on all DNS protocols.

However, applications that direct DNS queries towards a different

resolver from the one configured by the user in the system will

disrupt the functionality of these services.

Even applications that allow the user of a device to pick a different

resolver provide a way to circumvent these services. This is already

possible today, with unencrypted DNS; however, in traditional DNS the

administrator of the network has mechanisms to make a change of

resolver impossible, by mangling cleartext DNS traffic or by blocking

DNS connections to third-party resolvers. DoT makes this counter

action more difficult but still possible, as DoT traffic is normally

identified through its specific port number (see Section 2.3.4). DoH

makes this counter action almost impossible, as the protocol was

designed to make encrypted DNS queries undistinguishable from

normal HTTPS traffic – the network administrator would possibly

need to block all HTTPS traffic, breaking the entire network.

It is thus important that encrypted DNS clients do not override

the network administrator’s resolver-choice policies, to avoid dis-

rupting these services, and do not change the resolver that the

device is using unless the implications of disrupting these ser-

vices have been taken into account. Most operating systems and

browsers provide ways for enterprise IT administrators to prevent

the user from configuring a different DNS resolver. To address the

problem, some early DoH deployments in browsers have adopted

mechanisms (i.e. a “canary domain”) that network administrators

can use to signal that the browser should not turn on DoH towards

a different resolver. However, these are stop-gap measures while

waiting for the standardisation of better mechanisms.

Recommendation:

Operators that provide DNS-based services should make sure that the filtering engine is also active on their DoH and DoT resolvers, and should deploy available mechanisms to signal to clients that they should not send DNS queries to a different resolver.

They should also inform their users about the need to make

sure that all applications use that resolver. Clients that allow or

prompt the user to direct DoH/DoT queries to a different resolver

from the one configured in the system should take into account

the need not to disrupt these services, informing their users if

they do so, and should respect signals that network and resolver

operators may deploy to inform clients about the existence of

these services.


20

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry

DNS OVER HTTPS

6. User Level: User Choice and Awareness

Regardless of what option the user chooses, information duties

under applicable privacy laws must be fulfilled and a legal basis for

processing must exist. This may or may not entail obtaining user

consent, depending on the type of processing and the purposes

pursued by the data controller.

If any user interface has a default, best practice would prescribe

that application vendors should at least go through the effort of

undertaking a user survey in a given country or region. The moment

a choice is made on a user’s default, this needs to be based on

market intelligence about user concerns, in order to know what a

sensible default would be. While the scope of this paper is some-

what European, even different states within the US might not want

nationwide or global choices to be made on their behalf.

Recommendation:

Application developers should think carefully before changing the resolver by default, should consider the specific market and legal environment in each part of the world, and should make sure that their users are informed about the potential downsides and not only about the advantages.

Furthermore, application developers that establish pro-grams to validate and/or recommend resolvers should make sure that these programs are fairly accessible to any DNS operator (ISP or over-the-top) from any part of the world.

Finally, application developers should ensure that users are unambiguously informed about whether or not DoH is currently active.

6.1 Technology should be implemented to ensure choice for users & admins

A crucial factor in the implementation of DoH is to ensure that

the user or the network administrator can have control over the

choice of DNS resolvers. Currently, this provisioning takes place

via Dynamic Host Configuration Protocol (DHCP), which tells all

devices where they need to go, and this goes for all devices. If a

different application were to do its own DNS, there still needs to

be a way to tell all the applications on the device what the default

DNS resolver should be.

A default route to any provider that forces the user’s device to use

that resolver under all circumstances by overriding the configu-

ration on the operating system level should not be implemented

into an application. The user or the network administrator in a

corporate setting needs to be able to interfere with any choices

that the application makes.

Furthermore, no implementation of DoH currently available informs

the user of whether or not DoH is being actively used and the DNS

is being encrypted. Even if the end user has switched on DoH in

their application, this does not necessarily mean that DoH has

been activated and is in use. Therefore, alongside the questions of

informed consent handled above, end users should also be informed

of the actual status of their DNS requests.

6.2 Choice of default

Another point of discussion is the choice of default setting within

an application.

The contributors to this paper are in agreement that users should

be in control. However, they also acknowledge that certain users,

due to a lack of understanding of systems and consequences, for

example, are not very good at making those choices. Examples

of poor user choices can be seen in the lack of security measures

implemented in the devices of some users.

Therefore, in certain circumstances it may be important to pick

the default for the user (or recommend a trusted provider), taking

the view that this will improve user security and/or privacy, for

example. However, in choosing a default for users, it is not suffi-

cient to simply offer users the opportunity to change the default,

because the vast majority of users will not change it.


21

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry


At the international level, there is a discussion regarding network

discovery for DoH resolvers. The deployment model for traditional

DNS is that the resolver of the user’s ISP is default for that user.

However, if the user does not want to use that default, they can

simply enter a different one. With DoH currently, applications

do not have a standardised and automated way to discover DoH

resolvers, even if providers deploy them.

So far, some application vendors have attempted to discover which

resolver is configured in the operating system to upgrade it to DoH,

but none has implemented network discovery yet, though several

proposals for a discovery mechanism are under discussion at the

IETF and elsewhere. Those vendors actively working on DoH deploy-

ment are currently still using manual approval processes based on

personal communication with the person responsible. If DoH is to

become more widely deployed, then network discovery becomes

an important hurdle to be overcome.

Recommendation:

A network discovery policy could take the following form:

When an application starts, it should first check whether the user

has some configuration in place on the operating system that

asks the service or the application to use a given DoH server. If

there is no such policy in place, the application should look for

the network and ask if the network has such a policy in place. If

there is no policy in place for the network, it should fall back to

using DoH with a third-party provider to ensure encrypted DNS.

The contributors to this paper are in agreement that most Internet

service providers should have very strong incentives to offer

encrypted DNS, in order to continue being a part of the DNS eco-

system. In turn, the application vendors will be incentivised to

implement such a policy.

7. To be standardised: Network discovery


22

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry

DNS OVER HTTPS

The contributors to this paper fundamentally support the encryp-

tion of DNS information. Encryption of DNS has the advantage of

improving user privacy and security. However, the contributors

also concede that there are contexts where certain stakeholders

– for example, operators of a corporate network or Internet ser-

vice providers – may have concerns regarding potential downsides

of current implementations for encrypting DNS information. The

concerns generally do not relate to the DoH protocol itself, but

to the deployment model chosen by the applications, especially in

the context of web browsers.

8.1 Risks to privacy and security of unencrypted DNS – Why and where DoH is a good idea

DoH offers protection to communications in an untrusted environ-

ment, in particular public Wi-Fi hotspots. The encryption of DNS

traffic protects the user from the potential that a malicious actor

can listen in to the user’s DNS requests and perform cyber attacks

on the basis of this. Furthermore, the DNS query data in wireless

networks (in hotels, coffee shops, hospitals, shopping malls, etc.)

may be used to analyse customer behaviour and to track customers

across networks. DoH protects the user in these public wireless net-

works, as the DNS resolver of the Wi-Fi network is being bypassed,

preventing user tracking at this level.

However, DoH will not necessarily be the preferred option for spe-

cific trusted network environments. In corporate networks, DoH

should not be used unless the network itself asks for it. In home

networks, this depends on whether the user trusts their ISP or not;

DoH to other third-party DNS providers should be used when the

user does not trust the ISP, while if the user trusts the ISP, DoH

can be activated automatically towards the local ISP’s resolver; to

this purpose, applications should try to discover a DoH interface

to the local resolver through the local network.

On this point, there currently is no standard mechanism for the

system resolver to signal the existence of a DoH interface to it,

and for the applications to look for this signal. Efforts to solve this

problem are currently ongoing at the IETF.

Furthermore, no implementation of DoH currently available informs

the user of whether or not DoH is being actively used and the user’s

DNS is being encrypted. Application developers should rectify this

situation, ensuring that users are unambiguously informed about

whether or not DoH is currently active.

8.2 Risks entailed in certain DoH implementation models

8.2.1 Privacy & trackingThe DoH protocol, based on HTTPS, offers possibilities to track

users through the existing mechanisms that were developed for

the web (e.g. cookies, device fingerprinting). Furthermore, DoH

connections occur at the level of the device and even of the appli-

cation, meaning at the level of the user, meaning that it is possible

for the operator of the resolver to isolate the DNS queries for one

specific device or even one specific application.

8.2.2 Default DoH at the application levelMany of the concerns relating to corporate networks cease to

be concerns if DoH is implemented on a system level rather than

the application level (such as in a browser). At the system level,

corporate system policies are easier to handle: there are already

provisions to enable the use of different DNS resolvers depending

on which network the device is on. For example, the system can

be configured to select a specific non-local DNS resolver to over-

ride a public network resolver, but the moment the device is con-

nected to the office network, it will use the corporate network

DNS resolver, and likewise for the home network. However, if DoH

is implemented as default on the application level, these different

configurations are circumvented.

Furthermore, having an application use default third-party DoH for

DNS resolution means that different applications on the one device

may use different resolvers to reach the same destination, and be

retrieving different results – a scenario which can cause issues on

any type of network, including corporate networks.

In the event that a default setting is chosen for the user and imple-

mented into applications, as well as basing it on regional market

surveys, there should also be points awarded to a provider that

does not log.

8.2.3 CentralisationProvider centralisation – in combination with the possible tracking

capabilities of DoH – entails the risk of data collection points

where data regarding user behaviour would be aggregated on a

global scale. In the current implementation climate that has seen

the misuse of user data and privacy violations, such centralisation

can be a concern.

8. Summary


23

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry


Centralised DoH resolver providers could be very well intentioned

and believe deeply in providing a neutral, reliable encrypted ser-

vice, without gaining any benefit from the potential control such

a centralised position offers. There is, however, understandable

worry about commercial operators routing significant parts of

Internet control through their networks. Centralised operators

can counter such worries with privacy-focused user agreements

and public-facing audits.

How long this will remain a concern will depend on the number of

separate network providers and over-the-top DNS providers that

choose to deploy DoH resolvers and the model of implementation

of network discovery into the applications supporting DoH. With

increasing uptake, the privacy and dependency risks associated

with the centralisation of a major Internet resource will diminish.

8.3 Recommendations for implementing DoH

• In the first place, it would be advisable for DoH operators and

application developers to work together on an implementation

that safeguards privacy.

8.3.1 Deployment recommendations• The performance of the Internet as accessed over DoH will be

improved through the wide-scale deployment and uptake of DoH

resolution services offered by ISPs and network operators, as

well as over-the-top providers.

• Networks should be encouraged to implement their own DoH

resolver. If Internet service providers want to keep their own DNS

– for purposes of having visibility for malware filtering, or main-

taining control over routing and offering an up-to-date service

and encryption to their customers – they should make sure that it

is performant, and that they comply with local legal requirements.

Clients should either choose the “same provider” DoH deployment

model, adopting appropriate technical mechanisms to discover

the DoH equivalent to the currently configured DNS resolver,

or make sure that the legal implications of a possible change

of jurisdiction in DNS resolution are understood and addressed.

• If ISPs were to offer DoH alongside regular DNS, then the DNS-

based geographical filtering for CDN-caching distribution can

work without sacrificing privacy. If all of them offered their

own DoH, users would not have to switch DNS providers to get

encrypted DNS, and the ISP would still have the ability to direct

users to a closer destination.

• If providers of authoritative DNS services deploy encrypted DNS,

then disclosing the network location of the user would not be a

privacy issue. This would allow the authoritative DNS service to

provide the closest service node in the response sent to the user.

• Operators that provide parental control and other filtering ser-

vices via DNS should make sure that the filtering engine is also

active on their DoH and DoT resolvers, and should deploy avail-

able mechanisms to signal to clients that they should not send

DNS queries to a different resolver. They should also inform

their users about the need to make sure that all applications

use that resolver.

• DNS providers should implement DNSSEC: Alongside the above

recommendations for achieving the privacy-enhancing imple-

mentation of DoH in order to encourage the use of encrypted

DNS services, the contributors to this paper strongly advocate

the use of DNSSEC as a security enhancement for the commu-

nication of DNS information.

8.3.2 Legal recommendations• In line with the requirements of European privacy laws, users

should always be given clear information and a choice over

which operator will receive their DNS queries and through

which protocol.

• DoH implementations should ensure that user tracking is not

possible. This can be achieved by controlling the usage of web

cookies, device fingerprinting, TLS resumption tickets and other

techniques that could be used for tracking. DoH operators and

application developers should disable these features unless they

are clearly necessary for other functionalities (authentication,

performance), and in that case they should explain this to the

users and obtain their consent.

• Privacy-enhancing technology and techniques are encouraged

at all times, to complement encryption. This includes regarding

the handling of logging data. State-of-the-art technology and

techniques such as privacy-by-design, data minimisation and

data anonymisation are encouraged by the GDPR – which can

represent a best practice for privacy – when it comes to the

processing of personal data and should be deployed when pos-

sible. Operators of DoH resolvers should follow data minimisa-

tion principles, including with regard to logging data. If there is

a good justification for keeping any part of the logs, this needs

to be explained clearly and unambiguously.


24

ec

o —

Ass

oc

iati

on

of

the

In

tern

et

Ind

ust

ry

DNS OVER HTTPS

• Providers of a DoH service must comply with the GDPR if they

are processing the personal data of European users, in particular

the principle of data minimisation, and ensure they have a legal

basis for processing personal data. Furthermore, whatever imple-

mentation is chosen, the user should be able to control whether

information leaves the device or not. DoH providers need to ensure

that by default they have deactivated any tracking capabilities,

which should only be activated after having first performed

GDPR or equivalent information duties. DoH operators should

also release privacy policies that document if and how they use

these features of the protocol.

8.3.3 Implementation recommendations• DoH on the application level should not be a default setting.

DoH would be better implemented on the operating system level.

• Clients that allow or prompt the user to direct DoH/DoT queries

to a different resolver than the one configured in the system

should take into account the need not to disrupt any intranets,

filtering services and other local network policies and config-

urations based on DNS, informing their users if they do so, and

should respect signals that network and resolver operators may

deploy to inform clients about the existence of these services.

• Application developers should think carefully before changing

the resolver by default, should consider the specific market and

legal environment in each part of the world, and should make

sure that their users are informed about the potential downsides

and not only about the advantages. Furthermore, application

developers that establish programs to validate and/or recom-

mend resolvers should make sure that these programs are fairly

accessible to any DNS operator (ISP or over-the-top) from any

part of the world. Finally, application developers should ensure

that users are unambiguously informed about whether or not

DoH is currently active.

• Recommended discovery policy: When an application starts, it

should first check whether the user has some configuration in

place on the system that asks the service or the application to

use a given DoH server. If there is no such policy in place, the

application should look for the network and ask if the network

has such a policy in place. If there is no policy in place for the

network, it should fall back to using DoH with a third-party

provider to ensure encrypted DNS.

DISCUSSION PAPER: DNS OVER HTTPSDNS OVER HTTPS DNS OVER HTTPS

Imprint

Publisher:eco — Association of the Internet Industry

Lichtstrasse 43h

50825 Cologne

Germany

Layout:Hansen Kommunikation Collier GmbH,

Cologne, Germany

Contact:eco — Association of the Internet Industry

Phone: +49 221 - 70 00 48-0

Email: [email protected]

ImagesCover/Header Image:

© Turac Novruzova | istockphoto.com

© Andriy Mertsalov | istockphoto.com

© -WaD-| istockphoto.com

Recommendation Boxes © Inna Kharlamova | istockphoto.com

September 2020

eco — Association of the Internet IndustryLichtstrasse 43h, 50825 Cologne, Germanyphone +49 (0) 221 / 70 00 48 - 0fax +49 (0) 221 / 70 00 48 - 111 [email protected], https://international.eco.de

@eco_en, linkedin.com/company/eco-association

DNS OVER HTTPS

https://www.linkedin.com/company/eco-association

discussion paper: dns over https - norbert pohlmann

Documents