2. Focused Research

About the IIJ Public DNS Service

2.1 Introduction

As it became clear that DNS was also being monitoring

IIJ released the beta version of its IIJ Public DNS Service inunder PRISM, the IETF began developing mechanisms toMay. It is a caching DNS service that only accepts DNS overensure DNS privacy, until then a perfunctory affair, through

TLS (DoT) and DNS over HTTPS (DoH), meaning that it does

its new DPRIVE (DNS PRIVate Exchange) Working Group.

not support name resolution via the usual UDP/TCP setup,

DPRIVE has published various protocol extensions/revisions

and it is available to anyone, not just IIJ users.

for DNS, including Qname Minimisation (RFC 7816) andEDNS(0) Padding Option (RFC 7830, RFC 8467), with trans-

This report explains how DoT/DoH differs from the usual

port encryption being of relatively high importance among

DNS setup and describes key considerations and future

these efforts.

challenges for IIJ in providing this service.
2.2.2 DNS Transport Encryption

2.2 What is DoT/DoH

Traditional DNS mainly uses UDP for the lower-level pro-

2.2.1 DNS and Privacy

tocol (transport), supplementing this with TCP. However,Information registered to the DNS is assumed to be publicly

plain UDP/TCP, and DNS over UDP/TCP, do not have aand widely available. For a long time, therefore, the focus of

mechanism to provide confidentiality, and communications

DNS security has been to ensure that the information is not

are easily eavesdropped since they take place in the clear.

tampered with (i.e., that its integrity is maintained), whereas

A decision was therefore made to insert an encryption layer

ensuring that the information is not intercepted (i.e., that it

between DNS and the lower layers to provide protection.

remains confidential) has not been a priority.
Various encryption layers have been proposed, with the
In 2013, however, the Snowden affair revealed the exis-

following having been standardized so far: DNS over TLS

tence of PRISM, an extensive communications monitoring(RFC 7858), DNS over DTLS (RFC 8094), and DNS overand information collection program carried out by the US

HTTPS (RFC 8484). A draft of DNS over QUIC has also been

National Security Agency (NSA). This prompted the IETF to

submitted to the IETF and is now under discussion. And if

declare that “Pervasive Monitoring Is an Attack” (RFC 7258)

HTTP/3, which is also currently under discussion, is stan-and call for protocols to be designed to withstand pervasive

dardized, DoH will automatically support HTTP/3 (Figure 1).

monitoring going forward.

DoD

DoQ

DoH

Traditional DNS
(UDP)

(TCP)

DoT

DoH

DNS

HTTP/3DTLS

HTTP/2

QUIC

TLS

UDP

TCP

IPv4/IPv6

Figure 1: DNS Transport Protocols

10© Internet Initiative Japan Inc.

Nov.2019

Vol.

44

2. Focused Research

These various encryption layers are not integrated into any one

In general, encryption guarantees both integrity andprotocol; at present, you simply select whichever suits yourconfidentiality, but when it comes to DNS transport en-users’ circumstances. But flooding the space with a bunch

cryption, encryption only happens between the user andof different protocols can have its drawbacks, so it is quite

the caching server. Since communication between theconceivable that a subset will be selected, and the rest depre-

caching server and the authoritative server use traditional

cated, at some point in the future. (At present, DNS over DTLS

DNS (not encrypted), the integrity of the information ob-

is a specification only, with no existing implementations, and it

tained by the caching server cannot be guaranteed, andseems unlikely that it will become available for use.)

its integrity cannot be guaranteed even if the information
is protected by encryption. That is, unlike encryption in

2.2.3 Transport Encryption and DNSSEC

general, the DNS transport encryption protocol only guar-

DNS already has a mechanism for verifying DNS informa-

antees confidentiality between the user and the cachingtion via digital signatures called DNSSEC. So why do weserver (Figure 2).

need a new method of transport encryption when we have
DNSSEC? And will transport encryption eventually makeDNSSEC, meanwhile, was introduced to protect against

DNSSEC unnecessary?

data forging and manipulation. It uses digital signatures toguarantee integrity, but communication itself takes place in

Before answering this question, let’s look at the scope ofthe clear and is not confidential.

transport encryption. With DNS, clients do not directly query
the server on which the master DNS information is registered

So both transport encryption and DNSSEC are mechanisms(authoritative server); instead, they query caching servers

for improving DNS security, with one focused on guarantee-

provided by ISPs and other parties. In general, the cachinging confidentiality without integrity and the other focusedservers are responsible for querying the authoritative server.

on guaranteeing integrity without confidentiality. In thatsense, they are each other’s complement, so one cannot

Transport encryption is currently only performed between

replace the other. Each protects something different, which

the user and the caching server. Communications between

means that transport encryption does not obviate the need

the caching server and the authoritative server use tradi-for DNSSEC, and vice versa.

tional DNS and are not encrypted.

Root server

Registry’s
authoritative server

Caching server

User

example.com’s
authoritative serverProtected by DoT/DoH

Traditional DNS used
Figure 2: Scope of Transport Encryption© Internet Initiative Japan Inc.

11

2.3 IIJ Public DNS Service and DoT/DoH

Although it is known that using TCP would preclude or

DoT and DoH differ from traditional DNS only in terms of trans-

greatly reduce the threat of such attack methods, the mas-

port-layer protocol. They both use the same DNS protocol assive overhead that would result from the use of TCP withtraditional DNS. Yet we still had a number of barriers to over-

DNS—because DNS, by its nature, involves the exchange ofcome to provide them as a service. Let’s look at each in turn.

a large number of small packets—has dissuaded the community from shifting to TCP as the main transport protocol.

2.3.1 The TCP barrier

Even when the Kaminsky Attack*1, which allows vastly

The major difference between DoT/DoH and traditional DNS

more efficient cache poisoning that with previously known

is that all communications take place via TCP before being

methods, was revealed in 2008, we still didn’t switch toencrypted using TLS. While traditional DNS can use either

TCP and opted instead to make do with UDP and treat the

TCP or UDP as the transport protocol, in most cases UDP issymptoms with source port randomization*2.

used, with TCP only being used in limited cases.
So there was considerable aversion to the TCP overheadWith TCP, a session must be established before communi-with DNS, but requiring TLS naturally also means requiring

cations on higher-layer protocols can start. TCP also uses

TCP. The DNS over DTLS protocol, which uses UDP, does

various techniques to ensure the reliability of transmissions,exist, but it entails a large overhead just like TCP, and more-which include checking that sent packets were in fact re-over, no one can use it because it is only a specification; no

ceived and resending them if necessary.

implementations exist.

DNS involves very little data exchange. In most cases, both

Nonetheless, we must abandon the conventional wisdom if

the query and response rarely exceed a few hundred bytes.

we are to use it as a foundation for providing a secure cach-When TCP is used here, the process of setting up and later

ing DNS service. A major factor in enabling us to provide

terminating the session accounts for vastly more of thethe IIJ Public DNS Service without restriction to anyone incommunications exchanged than the actual DNS message, re-the world is that we do not use DNS over the low-reliability

sulting in extremely poor efficiency. Possible solutions to load

UDP protocol, which dispels concern of the service being

problems include the extravagant approach of simply adding

used as a launchpad for a DNS amp attack or such like.

more servers, but nothing can really be done about increased

We should focus squarely on the benefits that using TCP

latency stemming from an increase in packet roundtrips.

actually provides.

UDP has no such mechanisms, making it fast and simple,

2.3.2 The TLS Barriers

and it is widely used in protocols that involve the exchange

DoT and DoH eschew UDP and use TCP, resulting in aof small packets, such as DNS and NTP. Its reliability, onlarge overhead, and they employ a TLS encryption layer

the other hand, is low, and many of the attacks on DNS

above the TCP layer. TLS is widely used in HTTPS andthat have so far been discovered, such as cache poison-

elsewhere, but it is certainly not lightweight, and it causes

ing and DNS amp, really stem from the use of UDP in thesignificant performance degradation with protocols thatlower layer rather than from any problems with the DNS

necessitate the high-speed exchange of small amounts ofprotocol itself.

data, such as DNS.

*1

For example, JPRS Topics & Columns, “Aratanaru DNS cache poisoning no kyoui: Kaminsky Attack no shutsugen” [New DNS cache poisoning threat: Emergenceof the Kaminsky Attack] (https://jprs.jp/related-info/guide/009.pdf, in Japanese only)*2

Randomizing the source used by clients when sending queries increases the number of factors that an attacker needs to guess when seeking to forge packets,
which reduces the probability of a successful attack.

12© Internet Initiative Japan Inc.

Nov.2019

Vol.

44

2. Focused Research

Although logic says we will take a significant performanceback to NLnet Labs, and the latest available version now in-hit compared with traditional UDP-based DNS, we needcludes our code.

tools if we are to measure how much performance actuallydegrades. TCP-based DNS has been in use for some time,

Aside from performance issues, TLS poses one more barrier,albeit only in limited cases, and tools do exist. But DNS

namely that communications are encrypted.

over TLS is completely new. And there are no satisfactory
tools for measuring performance. We needed to measure

To ensure a stable DNS service, you need a mechanism thathow much performance degrades and what the processing

allows you to collect statistics to make sure that a large num-load would be so that we could estimate just how much

ber of abnormal queries are not being sent, and that abnormal

equipment we would need to provide the service, and to do

responses are not increasing despite the queries being normal,

this we had to start by developing performance measure-so that you can investigate and take action if abnormalities

ment tools.

do arise. With traditional DNS, in most cases this sort of statistics gathering and troubleshooting was done not on the

Since TLS involves a very high processing load, options

DNS server itself but by capturing DNS packets. Since thisare available to reduce the overhead by, for example, re-process can be performed independently of the DNS server,using information from a previous connection to resume

the same method can be used regardless of what DNS servera session (TLS session resumption) and, in TLS 1.3 (theimplementation is used.

latest version), adding the application data to the initial
ClientHello/ServerHello exchange that takes place during

But with TLS, the captured packets are encrypted. Perfect

the handshake (0-RTT).

Forward Secrecy (PFS) is now commonplace, so packets cannot be decrypted even if you have the server’s private key.

But having certain functions available in the TLS protocol isThis means that the tools so far used to collect information

meaningless unless applications actually use them. Running

are no longer viable. The ability to collect statistics is needed

services in a large-scale production environment will be diffi-

for private testing of course, and it is indispensable if you plan

cult unless you make full use of these options.

to make something widely available as a service, so much sothat you may as well shelve the service without it. So we

The IIJ Public DNS Service uses Unbound, a DNS implemen-

had to rebuild the statistics collection functionality from thetation developed by NLnet Labs in the Netherlands. It is quite

ground up to enable us to gather the same sort of information

old and supported TLS before DoT became an IETF draft.

from the DNS server without relying on packet capture, andWhen we investigated Unbound’s TLS support, however,with this in place we were finally ready to launch the service.

we learned that it lacked those mechanisms for reducing the
TLS overhead; specifically, it lacked TLS session resumption

2.3.3 The HTTP barriercapabilities. And performance measurements also indicated

The barrier posed by HTTP was actually not all that high.

that performance was inadequate. Further, performance differs greatly depending on what encryption algorithm is used,

With DoH, once TLS has been applied, the DNS message

but this was hardcoded into the source. So IIJ decided tomust then be encapsulated in an HTTP message. Getting

implement the necessary features. The results were passed

the DNS server itself to speak HTTP would be quite a© Internet Initiative Japan Inc.

13

challenge, but a two-stage setup where an ordinary HTTP

users are constantly unable to use the Internet because aserver receives the queries, converts the message format,

name cannot be resolved.

and passes them to a DNS server behind it would be prettymuch just like that used by any other Web application out

Moreover, it looks like performance is even worse on

there, aside from the fact that the backend is a DNS server.

Android 10 (currently under development as of this writing)than it is on Android 9.

Clearly because we are using TCP instead of the traditional
UDP, as well TLS, the latency and other performance issues

Other than this, we have had not major problems. Latency

are unavoidable. But because we take care of the hard parts

should theoretically be worse than with traditional DNS, but

in the HTTP layer, which has a proven track record, and not

it does not appear to be a problem in practice and we havein the DNS layer, which would require us to fumble aroundnot received any complaints.

in unfamiliar territory, this should not be seen as too muchof a setback.

DoT and DoH are still new technologies and the basic specifications have only just been finalized. A lot of the peripheral

2.3.4 Have we overcome the barriers?

specifications are yet to be sorted out (for instance, DoT/As of this writing, the service has been live for about six

DoH servers presently can only be configured by hand; net-months.

work administrators are unable to distribute configurations
for automatic deployment).

We did create a bit of a stir when we published the press
release since this is the first DoT/DoH service in Japan, andGoing forward, we will continue to investigate issues with

the Android DoH client Intra*3 subsequently added an IIJ

the aim of making improvements and implement new spec-

Public DNS list option for users to select (we did not evenifications that are on the road to becoming standards in thehave to ask for the option to be added).

hopes that people will be able to use the latest technologies
with peace of mind. And we will continue to give back by

I wish we could give a glowing account of how everything wentcommunicating the insights we glean from operating ouroff without a hitch post launch, but reality does disappoint.

service to the community.

As explained, Unbound did not have TLS session resump-

2.4 Public DNS and DoT/DoH

tion, so we implemented it ourselves, but TLS session

In closing, we look at developments beyond the IIJ Public

validity appears to be extremely short on Android 9, and our

DNS Service.

session resumption implementation has proved ineffective
in many cases. When Android smartphone users visit a Web

Originally, caching DNS servers were only available to users

page and then follow a link from that page to another one,within a particular organization. They were not public in na-

often the TLS session established to resolve the previous

ture. But the realization that making them public would notdomain name has already timed out and the whole processreally be all that harmful eventually led to most of them be-

has to start again with a handshake. This handshake fre-coming available without restriction (open resolvers). Later,quently fails if the network is congested, which means that

however, the DNS amp attack was discovered and attackers*3

14Intra (https://play.google.com/store/apps/details?id=app.intra)© Internet Initiative Japan Inc.

Nov.2019

Vol.

44

2. Focused Researchbegan to use open resolvers to stage DDoS attacks. So

services selected by Firefox would automatically be usedsince around 2010, the scope of access has generally been

unless the user configures the browser to do otherwise. But

restricted to the minimum necessary.

public DNS services, because they are public, cannot resolve
namespaces such as those found on intranets. And services

Meanwhile, other services aimed at a wide range of users

like parental controls that use DNS will be ineffective if thesought to foil attacks by implementing rate limitations andbrowser selects its own DNS server instead of what thethe like, rather than address-based restrictions. The pi-

OS settings dictate. In light of these points, there is debate

oneer here is OpenDNS , but this was later followed byabout the pros and cons of imposing DoH as default.

*4

the Google Public DNS*5 service, and ever since that gained
traction, these sorts of explicitly open resolvers have gener-

Google Public DNS supports DoT/DoH, and use of these

ally been called “public DNS” services.

protocols ensures confidentiality between the user and
Google. Meanwhile, Google also supports EDNS0 Client

The DoT RFC became a standard in 2016. The public

Subnet (ECS; RFC 7871). With ECS, when a client queries a

DNS service Quad9 , launched in November 2017, andcaching server, the caching server relays information about

Cloudflare*7, launched in April 2018, supported DoT fromthe network to which the client belongs to the authorita-

the start, and Google also added support in January 2019.

tive server. This is intended to be useful in content delivery*6

traffic management. But it is important to note that tradiDoH officially became an RFC in October 2018, but im-

tional DNS is always used between caching servers that

plementations based on the draft came out ahead of that.

use ECS and the authoritative server. If the user is using

Cloudflare provided support upon launch in April 2018,

DoT/DoH, communications on the route between the user

Quad9 added support two weeks before RFC 8484 was re-and Google will not be eavesdropped, but communications

leased, and Google also later added support in June 2019.

on the route between Google and the authoritative server
can be eavesdropped because traditional DNS, which does

On the client side of things, Android has supported DoT at

not guarantee confidentiality, is used here, and this could

the OS level since August 2018, and the DoH client app

result in a breach of user privacy since the ECS information

Intra was released in October 2018. Among Web browsers,

traverses that route.

Firefox added DoH support in August 2018. In Chrome’scase, only the development version supported it as of this

There is now a definite move toward encrypting DNS trans-

writing, but the stable version may also have it by the timeport, and it is unlikely to be stopped at this point. But as

this is published.

providers of a new public DNS service, we have an important responsibility not to blindly accept every development

Mozilla has stated that it plans to make DoH the default forthat unfolds but to evaluate each one by one and determinename resolution in Firefox , meaning that the public DNS

if it really is the right way to proceed.

*8

Takanori Yamaguchi
Application Service Section, Application Support Department, IIJ. Mr. Yamaguchi works on support for DNS services etc.

*4

OpenDNS (https://www.opendns.com/)*5

Google Public DNS (https://developers.google.com/speed/public-dns/)*6

Quad9 (https://www.quad9.net/)*7

Cloudflare (https://developers.cloudflare.com/1.1.1.1/)*8

Firefox Nightly News, “What’s next in making Encrypted DNS-over-HTTPS the Default” (https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-makingdns-over-https-the-default)© Internet Initiative Japan Inc.

15