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
DISCUSSION PAPER: DNS OVER HTTPS
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.
DISCUSSION PAPER: DNS OVER HTTPS
5
ec
o —
Ass
oc
iati
on
of
the
In
tern
et
Ind
ust
ry
DNS OVER HTTPS DNS OVER HTTPS
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.
DISCUSSION PAPER: DNS OVER HTTPS
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
DISCUSSION PAPER: DNS OVER HTTPS
7
ec
o —
Ass
oc
iati
on
of
the
In
tern
et
Ind
ust
ry
DNS OVER HTTPS DNS OVER HTTPS
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
User types URL:“international.eco.de”
System resolver(in operating
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
.de servereco.de server
.com
server
SoftwareApplication
Fig. 2 DNS resolution via DoH as implemented as default in an application
DISCUSSION PAPER: DNS OVER HTTPS
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/
DISCUSSION PAPER: DNS OVER HTTPS
9
ec
o —
Ass
oc
iati
on
of
the
In
tern
et
Ind
ust
ry
DNS OVER HTTPS DNS OVER HTTPS
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.
DISCUSSION PAPER: DNS OVER HTTPS
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/
DISCUSSION PAPER: DNS OVER HTTPS
11
ec
o —
Ass
oc
iati
on
of
the
In
tern
et
Ind
ust
ry
DNS OVER HTTPS DNS OVER HTTPS
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.
DISCUSSION PAPER: DNS OVER HTTPS
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.
User types URL:“international.eco.de”
System resolver(in operating
system)
SoftwareApplication
System resolver(in operating
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)
User types URL:“international.eco.de”
SoftwareApplication
(other server…)
(oth
er serv
er…)
go
og
le.c
om
ser
ver
.de servereco.de server
.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.
DISCUSSION PAPER: DNS OVER HTTPS
13
ec
o —
Ass
oc
iati
on
of
the
In
tern
et
Ind
ust
ry
DNS OVER HTTPS DNS OVER HTTPS
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.
DISCUSSION PAPER: DNS OVER HTTPS
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
DISCUSSION PAPER: DNS OVER HTTPS
15
ec
o —
Ass
oc
iati
on
of
the
In
tern
et
Ind
ust
ry
DNS OVER HTTPS DNS OVER HTTPS
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.
DISCUSSION PAPER: DNS OVER HTTPS
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.
DISCUSSION PAPER: DNS OVER HTTPS
17
ec
o —
Ass
oc
iati
on
of
the
In
tern
et
Ind
ust
ry
DNS OVER HTTPS DNS OVER HTTPS
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
DISCUSSION PAPER: DNS OVER HTTPS
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.
DISCUSSION PAPER: DNS OVER HTTPS
19
ec
o —
Ass
oc
iati
on
of
the
In
tern
et
Ind
ust
ry
DNS OVER HTTPS DNS OVER HTTPS
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.
DISCUSSION PAPER: DNS OVER HTTPS
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.
DISCUSSION PAPER: DNS OVER HTTPS
21
ec
o —
Ass
oc
iati
on
of
the
In
tern
et
Ind
ust
ry
DNS OVER HTTPS DNS OVER HTTPS
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
DISCUSSION PAPER: DNS OVER HTTPS
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
DISCUSSION PAPER: DNS OVER HTTPS
23
ec
o —
Ass
oc
iati
on
of
the
In
tern
et
Ind
ust
ry
DNS OVER HTTPS DNS OVER HTTPS
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.
DISCUSSION PAPER: DNS OVER HTTPS
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
Top Related