Using DNS-over-TLS with the Quad9 DNS Service

Recently the Quad9 DNS service was launched, a collaboration between IBM, Packet Clearing House (PCH) and the Global Cyber Alliance (GCA). According to the GCA, the Quad9 DNS server clusters are load-balanced with dnsdist and use a mix of Unbound and PowerDNS servers to deliver responses, giving the whole service a special Dutch flavour .

Quad9 differentiates from similar services by focussing on ease-of-use, scalability, security and privacy. One interesting and seemingly undocumented feature is the fact that you can communicate with the service using DNS-over-TLS. This encrypts the communication between your client and the DNS server, safeguarding your privacy.

We can get this functionality working using GetDNS, a modern asynchronous DNS API that NLnet Labs contributes to. As GetDNS is a library, we need a stub resolver that can talk to it. Stubby is a local stub resolver daemon that links with GetDNS to make this work on your system. Stubby is available for Windows, macOS and Linux. In this demo I’ll be using a Mac, so the easiest way to get started is by installing Homebrew, if you don’t already have it.

/usr/bin/ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Next, we can install Stubby.

brew install stubby

Stubby relies on a configuration file in YAML (Yet Another Markup Language), open stubby.yml in /usr/local/etc/stubby/ in order to edit it.

By default you’ll see that GETDNS_TRANSPORT_TLS is the only transport protocol that is enabled. For this demo, we want to keep it this way to make sure that we only communicate over TLS and have no means to fall back to TCP or UDP. We also want the usage profile to be ‘Strict’. This means that authentication information for the upstreams must be specified in the configuration file. Look for the line tls_authentication and ensure it is set to GETDNS_AUTHENTICATION_REQUIRED.

A little bit further down you will find a list with upstream recursive name servers that Stubby will send queries to. Several test servers are being operated by organisations such as SURFnet, Go6Lab and NIC Chile. All of them have an IP address, a hostname for TLS authentication and a Base 64 encoded form of SPKI pin(s) for TLS authentication (RFC7858).

We can query for the current SPKI pin for Quad9, but as DNS-over-TLS is an undocumented feature and we don’t know what their policy is, keep in mind that the key may be rolled by at any time. You can always get the latest SPKI pin with this command.

echo | openssl s_client -connect '9.9.9.9:853' 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

It should return with a value like this.

MujBQ+U0p2eZLTnQ2KGEqs+fPLYV/1DnpZDjBDPwUqQ=

Now we have all the required elements to edit the config file.

- address_data: 9.9.9.9
     tls_auth_name: "dns.quad9.net"
     tls_pubkey_pinset:
       - digest: "sha256"
         value: MujBQ+U0p2eZLTnQ2KGEqs+fPLYV/1DnpZDjBDPwUqQ=

Make sure you are careful with the spacing, YAML can be quite finicky about it. Next I comment out all of the other servers, make sure that Quad9 is the only one left. Save the file and we only have a couple of steps to go.

For Stubby to send outgoing DNS queries over TLS the resolvers configured on your machine must be changed to send all the local queries to the loopback interface on which Stubby is listening. To do this on my Mac, I run this command.

sudo /usr/local/opt/stubby/sbin/stubby-setdns-macos.sh

You can check in System Preferences that for the current network interface the DNS servers have changed to 127.0.0.1 and ::1. Looks like we’re ready to go, so the next step is to fire up Stubby pointing at the configuration file we just made and ensure that logging is enabled with -l so we can keep track of what its doing.

sudo stubby -C /usr/local/etc/stubby/stubby.yml -l

And behold…

Stubby successfully connecting to Quad9 over TLS

To learn more about DNS Privacy, please visit https://dnsprivacy.org/ , a collaborative open project to promote, implement and deploy DNS Privacy.

---

Update 17 January 2018: In case you’re a Mac user, I’ve been running the alpha version of StubbyManager for MacOS with no problems for several weeks now.

from https://medium.com/nlnetlabs/privacy-using-dns-over-tls-with-the-new-quad9-dns-service-1ff2d2b687c5
-------

Bringing DNS Security and Privacy to the End User

Encryption everywhere. It’s an initiative in the technical community that started as a reaction to Edward Snowden’s revelations about the NSA’s widespread surveillance and pervasive monitoring. For many, it was a wake-up call that resulted in advancing security best practices, such as stronger encryption on mobile phones and web traffic security services such as Let’s Encrypt. All of these efforts are aimed at protecting the complete path between the user and the service.

Authentication and encryption should start at the edge of the network, with the end user. As just about any interaction on the Internet starts out with a query for a domain name, it puts the DNS at the core of achieving security and privacy.

This road is not without hurdles, as we’ve managed to make the edge where the end user lives a complicated and perilous place, with NATs on top of Carrier Grade NATs, firewalls, a mix of IPv4 and IPv6 with translation mechanisms between them, and middle-boxes that rewrite packets or simply drop them on the floor. While traversing all of this complexity, we need to achieve two objectives with regards to the DNS:

1. Authenticity and integrity of the DNS data
2. Privacy of the user-DNS service transaction

DNSSEC allows for validation of the authenticity of DNS data. DNS-based Authentication of Named Entities (DANE) takes care of the authentication of the service by its public key (which can also be used to set up a TLS session). In this perspective, the DNS stub resolver is a key component to implement end-to-end security and privacy.

Although the stub resolver is considered a simple component in the DNS infrastructure, it has to work within the complex end-to-end properties illustrated earlier. Below is a diagram where you can see how the complexity of the DNS services compares to the complexity of the end-to-endness.

The complexity of the DNS services compared to the complexity of the end-to-endness

Stub resolvers have to deal with the most complicated end-to-end properties by far, but don’t forget some DNS resolvers don’t forward DNSSEC data, creating yet another hurdle. Let’s take a more detailed look at the impediments and the solutions to work around these problems.

DNSSEC Challenges for End-points

There are many different kinds of impediments to DNSSEC validation and DANE authentication. This section certainly doesn’t present all cases but focuses on the most eminent.

DNSSEC Roadblock Avoidance

Roadblock avoidance deals with DNSSEC validation at end-points that is often severely hampered by (budget) home routers and modems, but also other middleboxes between the end-point and the service. The IETF DNS Operations working group published a document on DNS Roadblock Avoidance (RFC 8027). It describes sophisticated techniques to assess upstream recursive resolvers for usefulness for DNSSEC.

An end-point implementing these techniques can determine the capabilities of the upstream recursive resolvers and eventually use a fallback strategy to act as a validating resolver, directly addressing authoritative names servers, if all in-between solutions fail.

NAT64/DNS64

In a period of transition from IPv4 to IPv6, the DNS infrastructure has to cope with a specific situation where IPv6-only endpoints need to address IPv4(-only) services. We will probably have to deal with this situation for the foreseeable future, so also, in this case, a robust solution is required.

For IPv6-only environments, NAT64 translates access to IPv4 address space by mapping it to IPv6 addresses within a certain prefix, and DNS64 delivers the synthesised IPv6 addresses. Note that ‘regular’ DNS would answer with an IPv4 address of the service. Obviously, these synthesised DNS messages are not authentic and DNSSEC verification would fail.

To make DNSSEC available in NAT64/DNS64 environments, a validating stub resolver must detect it is situated in a NAT64/DNS64 network and do the IPv6 synthesis itself, as described in RFC7050. This way, the IPv6-only end point is able to use DNSSEC to verify the DNS reply with the authentic IPv4 address.

A typical example in which you need these capabilities in the stub resolver is when you have configured your device to use privacy enabling recursive resolvers, such as Quad9, in an IPv6-only mobile carrier (or cellular) network.

DNSSEC Trust-anchor Maintenance

Every time we mention DNSSEC validation, we actually talk about the verification of the signature over the signed DNS data. DNSSEC validation is the construction of a chain of trust, starting from a trusted DNSSEC key and following it down to the DNSSEC key used to sign the DNS answer.

The trusted DNSSEC key you start with for every DNSSEC validation is called the trust anchor and is typically the key used to sign the root zone (formally called the Root Key Signing Key).

It’s clear that the management of the trust anchor is essential for correct operation of DNSSEC validating (stub) resolvers. As a result, a standard described in RFC5011 is proposed to track changes in the DNSSEC trust anchor. This standard is written with the idea that the validating resolver is a continuous running process with administrative privileges.

DANE validation is done at the application level and makes use of a stub resolver with user privileges, as illustrated in the earlier diagram. There is no guarantee when and for how long the application with the stub resolver will run and we cannot rely on RFC5011 to track trust anchor changes. However, there are no standards describing how applications should do trust-anchor maintenance yet either. A suggested method for user-space applications is a zero-configuration DNSSEC approach that relies on DNSSEC trust anchor bootstrap techniques described in RFC7958.

The Path Forward

To scale up security and privacy, a dependable stub resolver is a first requirement. In the DNS resolution chain, the stub resolver is crucial in providing authenticated DNS data and assuring privacy at the end-point.

Something we haven’t covered yet is how to provide verified DNS data and DANE validation to the application. We discussed how a stub resolver is able to reliably receive DNSSEC validated data, but not how the application can access it. It is essential to give application developers an easy to use and flexible DNS API to work with.

Two recent examples of DNS APIs are the systemd-resolved interface and the getdns API project.

Systemd uses systemd-resolved to provide the DNS functionality. Both components are part of the freedesktop.org project and applications can use the D-Bus interface for full-featured access to systemd-resolved, for example for DNSSEC validation status.

The getdns API project is jointly developed by NLnet Labs and aims to provide a flexible and modern asynchronous DNS API to application developers. The API is designed with input from application and system developers to match the requirements and expectations of the people that will eventually use the API. Either way, some standardisation of a DNS API and making it available on a multitude of platforms is important to improve on the current situation and increase the use DNSSEC and DANE by applications.

To set an example, the getdns API project has implemented many of the recent standards to achieve the goal of DNSSEC validation and DANE authentication at the end-points. This means it includes DNSSEC roadblock avoidance, IPv6 synthesis for NAT64/DNS64 environments, and has zero configuration DNSSEC.

The design and implementation of the getdns API also closely follows the development of the DNS privacy standard (DNS-over-TLS) described in RFC7858. It provides increased privacy for the user as passive observers can no longer see the DNS queries made by the client.

However, keep in mind that you still have to trust somebody to know your questions and provide answers. There is no complete privacy in a system which has intermediates (resolvers) between you and authoritative DNS servers. Even if you ask authoritative DNS servers directly, they know you asked. This is why it’s a good idea to review the privacy policy of the DNS service provider before making a choice.

The getdns API provides DNS privacy for legacy applications through a system component called Stubby. It runs as a daemon on the local machine, sending DNS queries to supported resolvers over an encrypted TLS connection.

You might wonder how this differs from Unbound, another NLnet Labs project, because that can also be configured as a local forwarder that uses DNS-over-TLS to forward queries. At the moment, Unbound does not have all the TCP/TLS features that Stubby has. For example, it doesn’t support ‘Strict’ mode or pad queries to hide query size and it opens a separate connection for every DNS query (Stubby will reuse connections).

As it stands, Unbound is a more mature and stable daemon but we are working on making Stubby just as robust. Note, it’s also possible to use the two together: Unbound for caching and Stubby for upstream TLS.

Lastly, the getdns API is also convenient and beneficial to app developers for the Android and iOS platform. Protecting data and privacy for mobile devices is an important subject for the next years to come and plans to support the getdns API for these platforms are becoming more definite.

---

The way that the Internet grows, develops and thrives has resulted in a complicated landscape. This makes securing it difficult, but there are open standards and running code that prove it can be done, offering security and privacy for everyone.

from https://medium.com/nlnetlabs/bringing-dns-security-and-privacy-to-end-users-with-dnssec-dane-getdns-stubby-3f7f5bb3b81d