Local and Internet Policy
Implications of Encrypted
DNSPaul Hoffman
ISOC-JP Seminar
30 October 2020

|1

ICANN’s document¤ Local and Internet Policy Implications of Encrypted DNS¤ https://www.icann.org/octo-003-en.pdf¤ Has been updated a few times since first version¤ Broad topics:

Filtering and monitoring in the DNS¡ Policy implications¡ Interested parties¡ ICANN’s positions¡|2

DNS participants
DNS root
Authority
Servers

DNS Stub
ClientDNS
Recursive
Server

DNS TLD
Authority
Servers

DNS
Recursive
ServerDNS
Authority
Servers

All those grey arrows are unencrypted communication“Encrypted DNS” is currently about the dotted ones on the left,from the stub clients to the recursive servers|3

DNS encryption: where¤ For now, encrypted DNS starts in a stub resolver and ends

at the recursive resolver¤ Until recently, stub resolvers appear only in operatingsystems¡

All applications call the OS for DNS service¤ In the past few years, browsers (and other browser-likeapplications) have added their own stub resolvers¤ The standards for DNS encryption assume that the client isacting as a stub resolver, and the server is acting as arecursive resolver|4DNS encryption: how¤ Two standardized protocols:

DNS-over-TLS (DoT)¡ DNS-over-HTTPS (DoH)¡ There are other non-standard protocols, but they only have thin
deployment¡¤ DoT: https://datatracker.ietf.org/doc/rfc7858/¤ DoH: https://datatracker.ietf.org/doc/rfc8484/¤ DoT and DoH have a large amount of overlap, but thedifferences are important to network operators|5

DNS-over-TLS¤ Basically: the stub resolver starts a TLS session with theresolver, and when the session is established, starts
sending regular DNS traffic over it¤ Authentication of the resolver is optional but needed toprevent on-path attacks¡Without authentication, the traffic is still unreadable by attackers
watching from the outside¤ Easy to set up: just need an IP address or domain name forthe resolver (the port number is fixed)|6

DNS-over-HTTPS¤ Basically: the stub resolver starts an HTTPS session (likenormal web browsing) with the resolver, and when thesession is established, starts sending DNS traffic that has
been wrapped in HTTP queries over it¤ If the HTTP is version 2, the server can also push DNS

content to the client, which the client can use or discard¤ Authentication of the resolver is mandatory because it ismandatory in HTTPS¤ A bit harder to set up than DoT: need a URL¤ DoH can re-use existing HTTPS connections because theservice is based on the URL|7

Policy implications¤ Increased privacy for users’ DNS traffic¤ Increased assurance for users’ DNS traffic¤ Circumvention of DNS filtering for security¤ Circumvention of DNS filtering for local policy¤ Circumvention of DNS filtering that is mandated bygovernments¤ Unwanted centralization of DNS resolution cannot bedetected¤ Speed of DNS responses|8Increased privacy and assurance¤ Privacy is a general good
¤ Encrypting DNS traffic protects users from observers on thepath between the stub and resolver¤ Encryption also prevents attackers from changing the traffic

in responses¤ Using DoT and DoH increases security for the DNS likeusing HTTPS in the web|9Circumvention of filtering¤ Network operators often filter or monitor DNS for the benefitof their users, or at least for the benefit of the health of theirsystems¤ Middleboxes that filter DNS for security (such as to preventmalware) and/or local policy (such as parental controls), arethwarted by encrypted DNS¤ Some filtering is mandated by the governments in somejurisdictions, so encrypted DNS can prevent those who arerequired to filter from complying with the law| 10Unwanted centralization¤ Clients that implement encrypted DNS can change where

the OS or application goes for DNS resolution¡

So can unencrypted DNS, but doing that makes it much more
obvious that a change was made¤ So far, this has been done only by Firefox

Their reasoning is that they only trust certain resolver operators tokeep Firefox users’ data private¡ They have a list of trusted providers, but that list currently has only
two operators¡¤ Concerns about privacy, reduced diversity leading to worse

resiliency, ossification, ...

| 11

Speed of responses¤ Starting a TLS session inherently is slower than justsending a bare DNS query¤ Overloaded resolvers might have long TLS startup times¤ DoH also requires converting DNS queries to HTTP

messages¤ However, early data indicates that while 90% of responses

are very slightly slower, the last 10% of responses aremuch faster because TCP is more reliable than UDP| 12

ICANN positions¤ Privacy is good
¤ Filtering of DNS can be beneficial¤ Applications and OSs have insufficient information to makenetwork control decisions, enforcement of legal mandates,and so on¤ DNS data should be protected| 13

Recent status¤ Mozilla is deploying DoH using a few trusted centralized

resolvers in different parts of the world¤ Google Chrome does automatic upgrade to DoT if theresolver supports it¤ Microsoft announced that it will add secure upgrade forresolver connections to Windows using DoH (not DoT)¤ More network operators have gotten involved in thediscussions of how encrypted DNS should be deployed| 14