Performance of Iodine over DNS-over-HTTPS
1–10 of 10 posts
Re: Performance of Iodine over DNS-over-HTTPS
#2Re: Performance of Iodine over DNS-over-HTTPS
#3Re: Performance of Iodine over DNS-over-HTTPS
#4Re: Performance of Iodine over DNS-over-HTTPS
#5TCP over TCP has always had serious performance issues, because the congestion controls combine in toxic ways. SSH tunnels that connect to something other than localhost on the remote end have similar problems (i.e. ssh -D 1080 as a SOCKS proxy).
Re: Performance of Iodine over DNS-over-HTTPS
#6Re: Performance of Iodine over DNS-over-HTTPS
#7Re: Performance of Iodine over DNS-over-HTTPS
#8If you can't send DNS packets directly to a remote resolver, do not expect bandwidth or stability for normal applications like a web browser. Use it for something like IMAP/SMTP, or browsing with lynx/links/w3m, or one-shot ssh commands, rsync, git, etc.
Would a ride-sharing app or navigation work?
I’m guessing there’s too much jitter/lag for a 9.6kbps phone call.
Re: Performance of Iodine over DNS-over-HTTPS
#9Re: Performance of Iodine over DNS-over-HTTPS
#10What's the purpose of doing this? If you're using Iodine it's presumably because normal HTTPS traffic won't work (e.g. captive portal), so tunneling your DNS back over HTTPS again is bound to fail in this scenario. It seems to me this would only work if the captive portal whitelisted known DoH servers (which seems rather unlikely).
I don't think I explicitly said that one should use iodine + DoH to bypass captive portals, but sorry if that somehow was implied.
The blogpost was just intended to be an experiment to compare the performance :-)