1.1.1.1: Fast, but not so accurate (yet)
The launch of Cloudflare's new 1.1.1.1 DNS service has brought much fanfare and a heap of praise. More choice is always a good thing, and support for both DNS-over-TLS and DNS-over-HTTPS make 1.1.1.1 an interesting option. In this post I'm going to explain why I won't use it yet, and why you might not want to switch either without doing some testing first.
Fastest isn't always best
Cloudflare touts 1.1.1.1 as "the Internet's fastest DNS directory." In terms of pure response time, they might be right. But when dealing with DNS, response time is only part of the equation. Just as important are the replies you get from a DNS server, the IP addresses it hands out in response to domain queries. Responses from centralized DNS services are sometimes unsatisfactory and can lead to service degradation. The answers come fast, but are they the right ones?
I like to use a telephone analogy here. Imagine you dial 9-1-1 and your call is answered so quickly you never even hear it ring. But it turns out you've been connected to a dispatcher in a city hundreds of miles away, and while she can send the authorities, it's going to take them awhile to reach you. The response was fast, yes, but it wasn't optimal. You would probably have preferred to speak to your local 9-1-1 dispatcher instead, even if you had to wait 3 or 4 rings for them to pick up the phone.
So, too, is the case with DNS. Public name servers may answer faster than your ISP's DNS, but that speed is negated if the servers they point you to are very distant.
Testing public resolvers for speed
Cloudflare makes bold speed claims, so I've done some basic testing to gauge how 1.1.1.1 stacks up against other options. Measurements were taken of the following DNS services:
- 1.1.1.1 - Cloudflare
- 4.2.2.4 - Level3
- 8.8.8.8 - Google
- 9.9.9.9 - GCA/PCH/IBM
- 75.75.75.75 - Comcast (customer-only)
Because 1.1.1.1 is promoted as a consumer DNS service, all observations below are from my residential Comcast cable connection in Memphis, TN.
Latency
Cloudflare's service appears to have robust connectivity and a diverse geographic presence. 1.1.1.1 is physically closer to me than other common public DNS options. The server I'm routed to, 172.69.197.23, is 7 network hops out, with an average ping of only 13.1 ms. It responds to an RFC4892 query with mem01, so is presumably located here in Memphis. That's about even with Comcast's 75.75.75.75, which also has an anycast presence in town, and it beats the other public resolvers. See the traceroutes for details.
NXDOMAIN
For the first round of DNS testing, I queried each server for 100 invalid domains in the .com zone to gauge NXDOMAIN response time. (4.2.2.4 hijacks NXDOMAIN and returns two advertising servers instead.)
[parse@word ~]$ for i in {1..100}; do dig A $(head /dev/urandom | sha1).com \
@1.1.1.1; sleep 5; done > 1.1.1.1.nxdomain.txt &Cold queries
Next, I queried 100 randomly generated hostnames on a domain configured for wildcard DNS. This test was intended to measure "cold" or uncached query response time.
[parse@word ~]$ for i in {1..100}; do dig A $(head /dev/urandom | sha1).shaun.ga \
@1.1.1.1; sleep 5; done > 1.1.1.1.cold.txt &Likely cached queries
Finally, I queried the top 100 domains on the Cisco Umbrella list. DNS servers are likely to have answers for these popular domains cached, improving response time.
[parse@word ~]$ head -100 top-1m.csv | cut -f2 -d"," | dos2unix > top-100.txt
[parse@word ~]$ while read host; do dig A $host @1.1.1.1; sleep 5; \
done < top-100.txt > 1.1.1.1.top.txt &The same series of tests was performed against all 5 DNS services. The output from each test was processed to calculate the mean average query times in millisecond...