There was an important development this month with the launch of Cloudflare’s new 1.1.1.1 DNS resolver service. This is a significant development for several reasons, but in particular it supports the new DNS-over-TLS and DNS-over-HTTPS protocols that allow for confidential DNS querying and response.
Why 1.1.1.1?
Before we get to that though, Cloudflare joins Google’s Public DNS that uses 8.8.8.8 and Quad9 DNS that uses 9.9.9.9, by implementing 1.1.1.1 as a memorable IP address for accessing its new DNS service. IP addresses are generally not as memorable as domain names, but you need access to a DNS server before you can resolve domain names to IP addresses, so configuring numbers is a necessity. And whilst a memorable IP address might be cool, it’s also proved important recently when DNS resolvers have been blocked or taken down, requiring devices to be pointed elsewhere.
The 1.1.1.1 address is part of the 1.1.1.0 – 1.1.1.255 public IP address range actually allocated to APNIC, one of the five Regional Internet Registries, but it has been randomly used as an address for so many things (e.g. for proxies), that it was overwhelmed with garbage traffic every time it was announced in the global routing system. The Cloudflare network is sufficiently scaled that it can cope with this traffic, so an agreement was established to allow APNIC Labs to analyse traffic to this address range in return for Cloudflare being able to use 1.1.1.1 for its DNS resolver project.
Under the agreement, APNIC also allowed Cloudflare to use the address 1.0.0.1 as the second IPv4 address for their DNS services, from a separate address range allocated for research. IPv6 addresses are also available, although at 2606:4700:4700::1111 and 2606:4700:4700::1001 they are not nearly so memorable.
Improving DNS Performance
It’s also important to have a fast and reliable DNS resolver service. Every device connecting to the Internet needs a recursive DNS resolver to translate names into addresses, which are usually provided by your ISP who’ll automatically configure your devices to point to them. However, ISP-provided resolvers can often be slow and unreliable (a problem I’ve encountered recently with an ISP that I use, and there’s some interesting comparison testing in this in this blog post), quite aside from the fact that locally-based servers have been blocked or censored by some national governments in response to civil unrest or politically embarrassing incidents. The likes of Cloudflare, Google, Quad9 and others provide alternatives, allowing users to choose better performing services with enhanced features rather than just having to rely on the default service offered by your ISP.
DNS Privacy
And this leads us to the most innovative feature of Cloudflare’s 1.1.1.1 DNS service. The DNS was never designed with privacy or security in mind, and whilst DNSSEC adds verification to the information returned by DNS queries, traffic is still sent unencrypted which allows anyone monitoring your network connection to see what you’re looking up and therefore visiting.
A couple of different solutions to this problem have recently been developed by the IETF, which we’ve discussed in previous blogs. The DPRIVE Working Group has developed DNS-over-(D)TLS, whilst the DOH Working Group has been working on DNS-over-HTTPS. The different protocols have different merits and try to address particular legacy behaviour of the DNS protocol (e.g. limitations on UDP packet size and the need for fast responses), but both approaches encrypt DNS queries and responses to provide confidentiality of these transactions.
So far so good, but there’s also a need for both resolvers and clients to be upgraded to support these protocols. Up until now, whilst some test servers have been set-up by various organisations, Google has been the only significant provider supporting DNS-over-HTTPS through their Google Public DNS and Android operating system. As a result, there’s been a certain reticence for other providers and vendors to build in support for protocols that rely on a competitor, but hopefully as more alternative resolver services are established, we’ll see increasing usage of these DNS privacy protocols.
Limitations
It should be pointed out that both DNS-over-HTTPS and DNS-over-TLS only encrypt DNS communications between stub-resolver (on the client device) and recursive resolver (e.g. Cloudflare 1.1.1.1). They do not currently encrypt the communications between the recursive resolver and authoritative DNS servers when resolving queries, so the provider of the resolver needs to be trusted as it still has the potential to monitor and log transactions. Neither does either protocol ensure the integrity of information returned from an authoritative server, which is why DNSSEC is also required to cryptographically assert the DNS entries are correct. They are nonetheless important components in improving the security and confidentiality of the DNS.
Implementation
If you’re interested in how to set-up a recursive DNS resolver and/or stub-resolver on a client device, you can find a lot of information over on the DNS Privacy website. Deploy360 also published a blog post last year on how we set-up DNS-over-TLS in the Go6lab which is well worth reading.
- What is 1.1.1.1? and the 1.1.1.1 web site
- Cloudflare 1.1.1.1 developer documentation
- DNS Privacy Project
- Deploy360: DNS-over-(D)TLS blog posts
- Deploy360: DNS-over-HTTPS blog posts
- DNS over TLS: experience from the Go6lab
- DPRIVE experimental service debuts @ IETF 99
- DNS Resolvers Performance compared: CloudFlare x Google x Quad9 x OpenDNS
We stand for a secure and trustworthy Internet. Help us protect it.
UPDATE: We should also note that Cloudflare’s 1.1.1.1 service also supports “Query Name (QNAME) Minimization”, as defined in RFC 7816. They include a reference to this at the end of their “Nitty Gritty Details” page:
Cloudflare minimizes privacy leakage by only sending minimal query name to authoritative DNS servers. For example, if a client is looking for foo.bar.example.com, the only part of the query 1.1.1.1 discloses to .com is that we want to know who’s responsible for example.com and the zone internals stay hidden.
Kudos to Cloudflare for implementing this higher level of privacy protection in their service.
Thanks to Stéphane Bortzmeyer for pointing out on Twitter that Cloudflare had implemented QNAME minimization. We had missed the small mention in Cloudflare’s technical blog post and weren’t aware they had included this.