|
Let's benchmark it:
I'm using unbound with the same configuration for each run, and Gibson's DNS Benchmark with DNSSEC testing enabled for all runs. The DNS server is the same across each, with only the forwarding configuration changed. I tested at the end of my VDSL line on an 80/20 connection.
20 pings to 1.1.1.1 (in ms):
Min: 5.116
Avg: 5.537
Max: 6.015
StdDev: 0.232
Fully Recursing to root DNS servers (UDP/53, in s):
Cached:
Min: 0.000
Avg: 0.000
Max: 0.001
StdDev: 0.000
Uncached:
Min: 0.005
Avg: 0.047
Max: 0.239
StdDev: 0.065
Dotcom:
Min: 0.008
Avg: 0.058
Max: 0.101
StdDev: 0.041
Normally forwarding through 1.1.1.1 & 1.0.0.1 (UDP/53, in s):
Min: 0.000
Avg: 0.000
Max: 0.001
StdDev: 0.000
Uncached:
Min: 0.006
Avg: 0.060
Max: 0.571
StdDev: 0.110
Dotcom:
Min: 0.007
Avg: 0.017
Max: 0.069
StdDev: 0.015
DNS over TLS Forwarding to 1.1.1.1 & 1.0.0.1 (TCP/853, in s):
Cached:
Min: 0.000
Avg: 0.000
Max: 0.001
StdDev: 0.000
Uncached:
Min: 0.069
Avg: 0.116
Max: 0.332
StdDev: 0.072
Dotcom:
Min: 0.068
Avg: 0.095
Max: 0.171
StdDev: 0.036
Conclusions:
1. Be aware that the pings are in ms and the DNS results are in seconds.
2. The Minimum uncached speed (0.005s) is the same as my ping time (5ms), meaning that my DNS resolution floor is the same as my line's latency.
3. This is the reason you use a caching DNS server on a local network: all cached results are basically 0 regardless of the method used to resolve by the server, and you bypass the latency on your line entirely, and I appreciate that my 5ms latency is much better than most folks.
4. The Maximum uncached speed is 239ms, which is when unbound has to traverse the entire DNS tree. For a worst case, that's ludicrously fast.
5. Using Cloudflare forwarding improves the Dotcom speed (common sites), but degrades the Uncached speed (worst case lookups), which makes sense as you're hitting a much more thoroughly tuned cache from thousands of users.
6. It is very strange that Cloudflare is slower to lookup uncached results, especially since Cloudflare host a very large fraction of the authoritative DNS records themselves, but the stats don't lie.
7. Using DNS over TLS halves the speed, again which makes sense as it is using TCP instead of UDP and has to roundtrip-ACK each packet, but in the worst case it doesn't make any difference. You can also see it's not exactly twice the times, because TCP is often prioritised over UDP.
So while I take your point that there are plenty of records that have a low TTL, you can also configure your local DNS server to basically say the TTL floor is 5 seconds or something (ie cache 0 TTL's for 5 seconds regardless), and save the DNS server doing extra effort. While it may be less accurate, it's so much faster and waiting 5 seconds for a domain to resolve properly is within the realm of a retry timeout.
The other thing to understand that is while DNS traffic can be sniffed, remember the fact that DNSSEC is also being used in the benchmarks above, so results cannot be faked. In other words, an ISP or 3rd party can see what I'm querying, but they can't do anything about it by spoofing the results like they normally do.
To stop them seeing, you need to use DNS over at tunnel. TLS is basically SSL with a modern cipher suite and SSL has always been a TCP-based tunnelling mechanism. OpenVPN and tinc however use UDP, so you can achieve the same (and probably faster) as DNS-over-TLS with using normal DNS through a VPN, knowing that OpenVPN and tinc will use OpenSSL's AES-NI acceleration to full capability as well.
The key takeaway, therefore is that DNS over TLS is a gimmick and doesn't provide any real upside. If prying eyes is a problem: use a VPN. If not, then a fully recursing DNS resolver is a much better solution, and you don't have to implicitly trust Cloudflare (even though they're damned good) either.
Proof enough?
|
Print Thread
deleted
