Learning From Public DNS Resolvers

DNS exists in a weird place in the modern network. It's foundational but also sometimes underappreciated and regularly blamed for everything that goes wrong.

It's important enough that ISPs generally run their own DNS services although they usually aren't great. For such an important service, "not great" doesn't cut it and so several major companies give away public DNS services for free, notably including Cloudflare's 1.1.1.1 and Google's Public DNS, 8.8.8.8, although there are several more with a bunch of options.

Since these public DNS services are pretty well known, they're interesting almost by definition; they're huge services handling a lot of traffic with intense uptime requirements. Let's take a look at them and learn some stuff!

IP Addresses in TLS Certificates

As a marker of identity, IP addresses aren't great; they're difficult for people to remember; legacy IPv4 addresses are expensive; and they're recycled regularly from old uses. That's where DNS comes along and largely shields us from IP addresses. That's a huge win; it's easier to remember domain names and being free to change IP addresses behind the scenes can be helpful.

There's a bootstrapping problem with DNS though in that we can't rely on DNS to resolve the address of a DNS server. That's why Cloudflare and Google's public DNS services are colloquially known by their IP addresses - e.g. 1.1.1.1 or 8.8.8.8 - and not by their domain names, even though both services do have domains which resolve to those addresses (more on that later!).

Since IP addresses are generally poor markers of identity, most things online which use TLS have certificates which include a domain name and not an IP address; Let's Encrypt will actually go so far as to refuse to issue certificates for IP addresses. But Cloudflare and Google are hosting websites on port 443 at the addresses their services are known by...

That means that - unlike the vast majority of web services - both Google and Cloudflare have TLS certificates which include the IP addresses of their services, as well as various domain names. As a TLS person by trade, IP addresses in publicly trusted certificates are a novelty I enjoy finding:

Easter Eggs in Domain Names

Despite the public DNS services being known chiefly by their IP addresses, we mentioned earlier that they there are domains which resolve to those addresses. At the time of writing, Cloudflare's domains lead to an informational site about 1.1.1.1 along with setup instructions, while Google's domains lead to a DNS resolver tool.

I think Cloudflare deserve a special mention here for registering one.one.one.one. You can easily imagine telling a person to go to "one dot one dot one dot one" and for them to type that domain into their address bar; so, mostly it's an Easter egg but it does also serve a purpose. Given that the ".one" TLD existed anyway, why not have some fun?

The existence of these domains does bring us back to that bootstrapping problem again though - when configuring DNS resolvers for their machine, a user can't really specify a domain name because they don't have a DNS resolver to resolve it!

Better DNS-over-HTTPS?

Most techy users will likely be just fine with the concept of using an IP address to configure their DNS resolvers, and so the possibility of bootstrapping issues is small for the tech-savvy. There is a place where I regularly encounter exactly the bootstrapping problem I described, though: Firefox's DNS-over-HTTPS (DoH) settings:

The actual domain name is viewable in "about:config" under the key "network.trr.uri", which at the time of writing has the value "https://mozilla.cloudflare-dns.com/dns-query". Firefox can work around this since in practice basically every machine which is running a web browser is going to have working DNS, and so Firefox can simply use the host's DNS just to resolve "mozilla.cloudflare-dns.com", and then use DNS-over-HTTPS going forwards.

The followup question though is... "Why use a domain name at all, though?" We've already established that Cloudflare runs an HTTPS server on https://1.1.1.1 so why couldn't Mozilla have used the IP address directly rather than a domain?

For one thing, mozilla.cloudflare-dns.com isn't 1.1.1.1: at the time of writing, the domain resolves to "104.16.248.249" among other addresses. Those addresses don't host a usable website right now; they give an HTTP 403 error, and only do so over HTTP, not HTTPS. So using, say, "https://104.16.248.249" just won't work because Cloudflare never configured it to work like they did for https://1.1.1.1.

If I change the DoH URI to "https://1.1.1.1/dns-query" it works just fine, though. Is that not strictly better from a user perspective?

The answer is yes: it is simply better. For end-users, I can't think of a benefit to using a domain here; if your system's usual DNS resolver went down but you're using DNS-over-HTTPS via https://1.1.1.1 you'd never notice anything wrong in Firefox because you wouldn't need the local server at all!

Even more important than resilience in the face of a local DNS failure is that a user machine's configured resolver could be actively malicious and refuse to resolve mozilla.cloudflare-dns.com - imagine an ISP trying to force its customers to use its DNS servers for tracking purposes. This isn't just theoretical; it does happen and you can see a few examples of people complaining about Cloudflare DoH being blocked if you search for it.

Google DNS works here too; you can use https://8.8.8.8/dns-query for DoH in Firefox and it'll work just great!

To be clear I'm absolutely not attacking Mozilla or Cloudflare for the use of a domain by default. The domain has a couple of upsides for Cloudflare and at the end of the day they're giving away their DoH service for free. It's totally reasonable for them to use this domain as a default.

Still, if you're tech-savvy and use Firefox with DoH, you might as well change to using an IP here and reap the rewards of having improved your DNS setup a little!