I polished my experimental DoH implementation repo
to include support for the most common public DoH servers as well as speeding
things up. I started this project more than 2y ago and it was the first
usable DoH Linux integration at the time being, when only
22.214.171.124 was available
and DoH was not an IETF RFC.
Yet, I was not really reading the RFC and still have my problems with DoH from privacy perspective (centralization of DNS lookups), even if it adds encryption.
Most DoH vendors still want you to install some weird proxy or tunneling software or rely on browsers supporting it natively. However, you can also just use this small footprint NSS module.
Since starting of the project quite some time has passed and we also have TCP Fast Open and TLS 1.3 available today, which has been integrated into harddns too.
So I again went ahead, comparing the three major public DoH services:
Lets start with Quad9. I like it because it has the best redundancy and seems the only of the three that actually offers that service on IPv6 too. Unfortunately, its neither supporting TCP Fast Open nor TLS 1.3 and therefore has the worst latency (“Open image in new tab”):
As can be seen there’s a normal TCP 3whs (you have to capture the 2nd TCP connection of corse)
and TLS 1.2. The wireshark dumps show a
ping kernel.org from 0 to the first ICMP Echo
thats leaving the NIC. Thats exactly the DNS lookup penalty. In this case its 0.16s.
Google is better with 0.11s latency of DoH turnarounds. You can see that the TLS Client Hello is within the first TCP packet, also carrying the SYN flag:
The best of three is Cloudflare with only 0.07s latency.
Additional to the Fast Opening, you also see TLS 1.3 which has a shorter handshake sequence.
This comparison explains why I re-ordered the nameserver list in
to connect to
126.96.36.199 at first.
I hope that Quad9 will soon add TCP Fast Open and TLS 1.3, as this is just a minor config thing (depending on the web server used). At the end, if you want to compete with the others, latency of DoH is key. Even if you have better redundancy. If the browsing session feels non-interactive, nobody will stick with it at the end.
Of corse, the efficiency of the server software itself also adds to the latency, but thats also a solvable problem, in particular if you have lot of nodes that you can actually distribute the requests to; and I also assume that all candidates use some form of caching their DNS lookups so that they do not have noticeable latency in their backends.