[1] in the original meaning of the word. [2] https://github.com/yarrick/iodine
I kept a log of all train/hotel/airport/etc networks that it worked on, and also offered some other tunneling protocols.
Was a fun project for a while. Wish I’d kept the thing running.
These days DNS tunnelling is a bit harder to do due to some DNS servers (notably Google) randomising the case in DNS requests which breaks certain encodings horribly.
Had a Delta flight that used gogoinflight internet. On my initial outbound flight I noticed DNS still worked without paying, so when I was flying back home, I had set up a simple iodine tunnel on my homelab in advance.
I was surprised by how completely unusable it was. Of the few sites I even attempted to load, I only just barely managed stallman.org after modifying my browsers maximum timeout via a flag (and it look ~5 minutes).
SSH was also not usable, even a simple "whoami" took ~1 minute to finally execute.
So yeah fun as a cool gimmick, but other than _maaaaybe_ connecting to a single IRC channel, its not practical for anything.
Let's say the plane's DNS server is 192.168.1.53 and your DNS server is 1.1.1.53
You can't talk to 1.1.1.53 because that's blocked, so running wireguard on 1.1.1.53:53 doesn't help you. Instead, you run iodine there and configure "*.mydomain.com" to have 1.1.1.53 as its dns server.
Now, you can talk to 192.168.1.53 to make DNS queries, and then the dns server there, which isn't firewalled, will forward to 1.1.1.53:53, and proxy back the response.
Obviously, the plane's DNS server won't speak wireguard, nor forward wireguard for you.
That's the usecase for iodine, when you have access to some local DNS server which will forward requests for you, but you don't have access to the public internet, so you can access your own DNS server indirectly and thus do IP-over-DNS that way.