dnstt performance

These are tests of dnstt download performance I did on .

Update : I updated the tables and figure to exclude a preliminary test run that I did not intend to include in the first place. The change did not affect any of the qualitative observations. The Cloudflare/DoH case increased by about 7 KB/s from 126.7 KB/s to 133.5 KB/s; none of the other cases changed by more than 3 KB/s.

The source code for these experiments is available in the following repo. I used git-annex to store the data files (there are over 3 GB of pcap files). You will have to git annex get the data files you want after git clone. The .csv files are sufficient to reproduce the graph. See procedure.txt for the commands to run to reproduce the experiment. .keylog files are TLS secrets in NSS Key Log Format; you can use these in Wireshark to decrypt the DoH and DoT streams.

git clone https://www.bamsoftware.com/git/dnstt-tests.git
cd dnstt-tests
git annex get 2020-04-30/*.csv
Rscript graphs.R

"KB/s" is kilobytes per second. I used the convention KB = 1024 bytes.

Original post.

David Fifield <david@bamsoftware.com>

dnstt download speed tests

I did some experiments of download performance of the DNS tunnel. tl;dr a DNS tunnel can go faster than you may think, but the choice of resolver matters a lot.

I tried downloading a 10 MB file through the tunnel, using a selection of resolvers and DNS transports. I cut off the download after 10 minutes. "none" is the special case of no intermediate recursive resolver (the tunnel client sends queries directly to the tunnel server). The server was located in Fremont, US and the client in Tokyo, JP. There was about 100 ms of latency between the two hosts. Download rates are the median of 5 trials. The dnstt tag was v0.20200430.0.

Cloudflare's DoH and DoT resolvers are both fast. Google's DoH resolvers is much faster than its DoT server (I noticed the DoT server terminating TCP connections every 200 KB or so). Comcast's DoH and DoT resolvers have about the same middling performance. Quad9's DoT resolver is notably slow; there's clearly something wrong there, whether it's the resolver or how the tunnel uses it. For comparison, the download rate of an untunnelled, direct TCP transfer was 4666.3 KB/s.

resolvertransportdownload rate
noneUDP187.1 KB/s
CloudflareDoT156.9 KB/s
CloudflareUDP156.4 KB/s
GoogleDoH135.1 KB/s
CloudflareDoH133.5 KB/s
ComcastDoT68.5 KB/s
ComcastDoH66.3 KB/s
Quad9UDP58.9 KB/s
GoogleUDP43.1 KB/s
PowerDNSDoH38.0 KB/s
GoogleDoT35.4 KB/s
Quad9DoH30.9 KB/s
Quad9DoT1.2 KB/s

I repeated the experiment with iodine, an existing DNS tunnel. iodine works over plaintext UDP only. dnstt is faster than iodine in every case, except for the Quad9 DoT resolver. It is possible to run iodine over a DoH proxy; I didn't try that myself but Sebastian Neef reports 4–12 KB/s when tunneling iodine through dnscrypt-proxy.

resolvertransportdownload rate
noneiodine14.6 KB/s
Googleiodine1.8 KB/s
Cloudflareiodine1.4 KB/s
Quad9iodine0.3 KB/s

This graph shows the 5 trials under each experimental condition and gives an idea of the variance. Steeper lines are better.

Line graph showing the number of bytes downloaded over time for dnstt/UDP, dnstt/DoH, dnstt/DoT, and iodine, over a selection of public resolvers.