DNS-over-TLS and DNS-over-HTTPS

Since September 2018, the University of Cambridge's central recursive DNS servers (known as rec.dns.cam.ac.uk) support encrypted queries. This is part of widespread efforts to improve DNS privacy by encrypting DNS traffic.

You can make DNS queries using:

  • Traditional unencrypted DNS using UDP or TCP on port 53 ("Do53")

  • DNS-over-TLS on port 853 ("DoT") - RFC7858

  • DNS-over-HTTPS on port 443 ("DoH") - RFC8484

These services are only available to devices on the CUDN.

Configuring DNS-over-HTTPS

The supported server URI for POST requests is

    https://rec.dns.cam.ac.uk/

and for GET requests the URI template is

    https://rec.dns.cam.ac.uk/{?dns}

You can configure very recent versions of Firefox to use DoH by going to Preferences -> General -> scroll to Network Settings at the bottom -> Enable DNS over HTTPS, Custom: https://rec.dns.cam.ac.uk/.

For more advanced options, go to about:config and search for trr. ("trr" stands for "trusted recursive resolver".) There are a number of trr configuration options. You can visit the DNS tab in about:networking to observe Firefox's DNS activity and to confirm it is using DoH.

Firefox and Cloudflare

We have configured our DNS blocks to tell Firefox not to use Cloudflare for DoH by default though you can explicitly opt in to using non-University DoH providers if you wish.

ESNI: encrypted server name indication

If you have enabled DNS-over-HTTPS you may also like to enable ESNI. Go to about:config and verify that network.security.esni.enabled is true.

When connecting to a web server the browser needs to tell the web server which site it is looking for. HTTPS does this using Server Name Indication, which is not encrypted unlike the rest of the connection. ESNI fixes this privacy leak.

DNS-over-TLS server authentication

DNS-over-TLS is commonly used opportunistically, without authenticating the server. For example, this is what Android does. In this case TLS protects against casual snooping; to prevent active interception you need to authenticate the server.

There are two supported ways to authenticate the server's certificates:

  • normal PKIX validation using the server name rec.dns.cam.ac.uk (which is the method used in the examples below)

  • verify this SPKI pinset matches:

    sha256 YcUU22CT7d/0t5wewjyUSeOfpFJ0nZCpeR0xSFxDIO4=
    

This is a certificate subject public key information fingerprint. These were invented for HTTP public key pinning, but they can now also be used for DNS-over-TLS authentication. You can get more information about HPKP from Scott Helme.

Sadly our TLS certificate provider does not support IP addresses in certificates, so we do not currently have the option of using PKIX validation directly against the DNS server addresses.

Example settings for Knot Resolver

"Knot Resolver" is a recursive DNS server. The following settings will forward queries from kresd over TLS to Cambridge's recursive DNS servers. On Debian you can put this in /etc/knot-resolver/kresd.conf:

    policy.add(policy.all(policy.TLS_FORWARD({
      { '131.111.8.42', hostname='rec.dns.cam.ac.uk' },
      { '131.111.12.20', hostname='rec.dns.cam.ac.uk' },
    })))

Example settings for Stubby

"Stubby" is a DNS privacy daemon. To use Cambridge's recursive DNS servers, replace the upstream_recursive_servers section in the default configuration file with the following. On Debian systems you can put this is in /etc/stubby/stubby.yml:

    upstream_recursive_servers:
      - address_data: 131.111.8.42
        tls_auth_name: "rec.dns.cam.ac.uk"
      - address_data: 131.111.12.20
        tls_auth_name: "rec.dns.cam.ac.uk"

Example settings for Unbound

"Unbound" is a recursive DNS server. The following settings will forward queries from Unbound over TLS to Cambridge's recursive DNS servers. On Debian you can put this in /etc/unbound/unbound.conf.d/dns-over-tls.conf:

    forward-zone:
      name: "."
      forward-addr: 131.111.8.42@853
      forward-addr: 131.111.12.20@853
      forward-tls-upstream: yes

Versions 1.7.1 and later support TLS server authentication, as follows. (You might need to adjust the path to the certificate bundle on non-Debian systems.)

    forward-zone:
      name: "."
      forward-addr: 131.111.8.42@853#rec.dns.cam.ac.uk
      forward-addr: 131.111.12.20@853#rec.dns.cam.ac.uk
      forward-tls-upstream: yes
    server:
      tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"

Our DoT / DoH server software

The software we are using to support DNS-over-TLS and DNS-over-HTTPS is a locally-developed hackathon project called doh101. It uses OpenResty which is a server platform based on nginx and LuaJIT. Nginx has a TLS proxy that provides DNS-over-TLS; a small amount of Lua implements doh101's DNS-over-HTTPS framing.

Further privacy information

This section explains what personal information we gather on the University of Cambridge's DNS servers.

The DNS servers are covered under the authorization for use of the CUDN and the University IT facilities and services privacy notice which set out how we handle your personal information about your use of the University's network.

We do not normally log queries made using the traditional DNS protocol over UDP and TCP on port 53, though we may do so in order to investigate problems.

For DNS-over-TLS, the servers log your IP address and the date and time of the request.

For DNS-over-HTTPS, the servers log your IP address and the date and time of the request. For GET requests (but not POST requests), the DNS query is also logged in an obfuscated format.

These logs are retained for up to two weeks.