BIND Implements DoH

DNS over HTTPS (DoH) in BIND 9

The February 2021 development release of BIND (9.17.10) comes with initial support for DNS-over-HTTPS (DoH). DoH is a major feature for end-user privacy. DoH conceals DNS traffic inside HTTPS to make it harder for third parties to analyse, intercept, and modify. Deployment of DoH is also a significant stepping stone for wider adoption of the Encrypted Client Hello (ECH) and Encrypted Server Name Indication (ESNI) features of the Transport Layer Security (TLS) protocol. These features further improve users’ privacy by preventing third parties from snooping, and by making it harder to block websites by analysing and intercepting TLS handshake requests. Without ECH, TLS handshakes by default contain server names in unencrypted form.

DNS-over-TLS (DoT) is a popular alternative to DoH. BIND also supports DoT. A BIND server can accept queries over traditional DNS (aka Do53), DoH, and DoT. Which transport is used for an individual client query depends on what the client uses to contact BIND.

The initial release of DoH is in a development release. Since this is an experimental feature, details are subject to change. As soon as this functionality matures enough, we will backport it into the current stable branch (9.16.X).

BIND’s DoH implementation is based upon the nghttp2 library written by Tatsuhiro Tsujikawa. In BIND 9.17.10 nghttp2 is a hard build requirement. (*we will fix this before we backport the feature to a stable branch.) It is safe to say that starting from this release we have a specialised HTTP/2 server built into BIND specifically to serve DNS-over-HTTPS queries.

BIND’s support in this initial release is server-side only. There is no DoH support for dig yet. We are working hard to fill this particular missing piece in a forthcoming release. So, for now, to test if DoH is functional one needs to use a third-party tool. We have tested it with Mozilla Firefox, kdig from Knot DNS and DNS dog. For a list of DoH clients, see the DNS Privacy Project website or the curl project page on DoH.

Features of the BIND DoH implementation

Despite being experimental, and the most recent major addition to BIND’s functionality, our DNS-over-HTTPS implementation has some unique features.

Firstly, even though DoH was designed to protect lookups from clients to caching resolvers and DNS load balancers, BIND also has native DoH support for the authoritative DNS server as well. The DoH transport layer should work in the same way as any other transport layer for DNS, so BIND over DoH should handle any DNS request you could expect from other DNS transports. It is not clear how this might be used yet, but it is interesting to note.

The second unique feature is the ability to offload TLS encryption to another server. We added this feature because, in some environments, management of TLS certificates is tied to control of web infrastructure and, thus, is the responsibility of other teams and individuals. For these and similar scenarios, we added to BIND ability to serve unencrypted HTTP/2 connections over TCP, so that encryption might be applied later. Having unencrypted HTTP/2 streams might also make troubleshooting (e.g. using Wireshark) easier.

An important thing should be said regarding TLS-offloading. The software which performs offloading needs to negotiate HTTP/2 over TLS connection using the Application-Layer Protocol Negotiation (ALPN) extension; otherwise, many DoH clients will assume that the established TLS connection is for HTTP 1.1. BIND does not support HTTP versions prior to HTTP/2, and will fail to perform name resolution.

How to DoH with BIND

Enabling DoH in the development release of BIND is as easy as adding a couple of options to the BIND configuration file. Here is a simple example for a recursive resolver:

# Private Key and certificate pair for TLS
# can be omitted if TLS offloading is being used
tls local-tls {
 	key-file "/path/to/priv_key.pem";
 	cert-file "/path/to/cert_chain.pem";
};

# HTTP endpoint description
http local-http-server {
 	# multiple paths can be specified
 	endpoints { "/dns-query";  };
};

options {
	listen-on port 53 {any;};
	listen-on-v6 port 53 {any;};
	allow-recursion {any;};
	# default ports for HTTP and HTTPS
	http-port 80;
	https-port 443;
    
	# example for encrypted and unencrypted DoH
	# listening on all IPv4 addresses.
	# port number can be omitted
	listen-on port 443 tls local-tls http local-http-server {any;};
	listen-on port 80 http local-http-server {any;};

	# the same for IPv6
	listen-on-v6 port 443 tls local-tls http local-http-server {any;};
	listen-on-v6 port 80 http local-http-server {any;};
};

Here https-port and http-port set the default port numbers for encrypted and unencrypted HTTP, for the case when a port number is omitted from listen-on statements.

The configuration format might seem a bit wordy considering that there is not much to configure in the DoH layer now, but we specifically decided to settle on this format because it is easily extendable.

Offloading TLS processing

To perform TLS offloading, one could consider using NGINX, but other options are also available: this is the one which we used during development. The main requirement is the ability to handle ALPN properly, as was stated earlier.

In order to perform TLS offloading for DoH, one can add the following to the NGINX configuration file (into the http {...} section):

# address and port of the DoH server, serving unencrypted HTTP/2
upstream http2-doh {
	server 192.168.8.8:80;
}

server {
	listen   	443 ssl http2;
	listen  [::]:443 ssl http2;
	server_name  example.com; # domain name
    
	# TLS certificate chain and corresponding private key
	ssl_certificate /path/to/cert_chain.pem;
	ssl_certificate_key /path/to/private_key.pem;

	location / {
		grpc_pass grpc://http2-doh;
	}
}

Provided that the software was correctly configured, after starting it one should be able to use DoH via a domain name specified in the NGINX configuration. In the example above, the DoH endpoint address would be

https://example.com/dns-query

The BIND 9 Administrator Reference Manual explains how to configure a BIND resolver to listen for DoH queries arriving over HTTP.

Support for DNS-over-HTTPS in BIND is an experimental feature not yet ready for production use. We encourage everyone who is interested in deploying it to try it now and report back any problems or give us suggestions if something is lacking. We would be happy to get as much feedback on it as we can!

Still on our “to-do” list

• add client side support so dig can launch DoH queries
• add counters for DoH traffic (increment existing counters for TCP traffic for DoH queries)
• add system-level tests (we have unit tests already)
• remove the requirement to build with the nghttp2 library for users who don’t want DoH support
• consider enabling XFR over DoH (let us know if you would use this!)
• backport DoH when stable to a 9.16 version (April or May most likely)

FAQs regarding DoH

What is DoH?

DNS over HTTP is a way to transport DNS queries and responses via HTTPS URIs, using the TLS security provided by HTTPS to encrypt those messages. DoH is defined by IETF RFC 8484 for communications between a DNS client and recursive resolver. It is an alternative transport to the long-time standard “native” DNS, carried in UDP packets and received over port 53.

What problem does DoH address? What is the benefit of DoH?

Ordinary unencrypted DNS queries send the information about the DNS name being queried in the open, leaking potentially sensitive information about the client. The DNS Privacy Project has a great summary of the issues DoH and DoT are addressing. DoH provides one way to encrypt the DNS queries from the client to the recursive resolver, thus keeping the content of this exchange confidential from the transport layer. It does not ensure that the answers from the resolver are authentic, as published by the domain authority.

To quote RFC 8484:

“Two primary use cases were considered during this protocol’s development. These use cases are preventing on-path devices from interfering with DNS operations, and also allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing (CORS) [FETCH].”

The original motivation for DoH was to offer the end user a way to bypass their access provider’s DNS system, and to prevent their access provider from snooping, blocking or monetizing their DNS query traffic. With DoH, these queries are directed at a specified server which may or may not be in the access provider’s infrastructure. The DoH queries are only visible to whomever is operating the DoH server. There was also a sense that tying the DNS to the HTTP/browser application would enable greater efficiencies, since most DNS lookups do lead to an HTTP connection.

DoH References

• ISC Blog on DoH - https://www.isc.org/blogs/doh-encrypted-dns/
• DNS Privacy dot org - https://dnsprivacy.org/wiki/ is an excellent, authoritative resource on the different DNS privacy solutions and how they compare.
• Jan Schaumann’s blog on DoH, https://www.netmeister.org/blog/doh-dot-dnssec.html
• Excellent summary of one enterprise’s choice with respect to the DoH/Firefox controversy, as of September 2019 - from Tony Finch of Cambridge University, https://www.dns.cam.ac.uk/news/2019-09-19-dont-use-application-dns.html
• NSA (US National Security Agency) brief on ‘Adopting Encrypted DNS in Enterprise Environments’, January 2021, https://media.defense.gov/2021/Jan/14/2002564889/-1/-1/0/CSI_ADOPTING_ENCRYPTED_DNS_U_OO_102904_21.PDF

What are the Concerns About DoH?

Increased Network Security Risk

One of the significant characteristics of DoH is that it makes DNS traffic indistinguishable from the much higher volume HTTP traffic. In well-managed networks, DNS is used as a control point to identify and block suspected abuse or unwanted traffic, using RPZ or other mechanisms for DNS filtering. DoH renders these measures ineffective.

There have also been exploits discovered in which DoH is used specifically to hide and transport malicious code.

DNS Provisioning

In traditional DNS (Do53) the client is provisioned with the address of a DNS service, typically in a DHCP option when the client obtains its IP address. This information is obtained and provided at the operating system level. With DoH, some browser implementations wanted to provide for a DNS setting at the application level, that could be different from the operating system setting.

One significant issue with the design of DoH is how to configure the client with an appropriate DoH server. Several web browsers are shipping with a few DoH providers helpfully pre-loaded, the same way they might pre-configure Google as the default search engine. The IETF Working Group on Adaptive DNS discovery is working on specifying methods for client discovery of DoH servers.

Centralization of the Internet

There is a significant and well-founded concern that adoption of DoH will lead to more centralization of DNS query traffic, which in turn is bad for freedom and privacy on the Internet.

Centralized DoH is bad for privacy - RIPE NCC Blog by Bert Hubert, https://labs.ripe.net/Members/bert_hubert/centralised-doh-is-bad-for-privacy-in-2019-and-beyond

Given all this controversy, why did ISC implement DoH in BIND?

We try to implement the major DNS RFCS in BIND, so that it can be a reference implementation, to the extent possible. It is not always possible for us to implement every RFC but we felt this one was consequential. We want to enable people to run services on the Internet, and implementing DoH is part of that. We cannot prevent the centralization of control on the Internet, but we can provide open source that enables operators to offer competitive services.

(FAQs added by Vicky Risk, any mistakes are hers)