Simplicity / latency / efficiency - DNS typically just fires off one UDP packet (generally one IP packet & ethernet frame too) and then gets one back (hopefully) and it's done. HTTP requires the TCP 3-way connection handshake, then the out & back roundtrip for request/response, then the 4-way teardown handshake. If it's HTTPS you also need the 4-way TLS <= 1.2 handshake and close notification alert. Although QUIC or TLS 1.3 improves that a bit.

Anyway if you're using a 14.4 modem in a rusty bunker at the bottom of the sea you'll notice a substantial improvement :)

This.

I measured the difference using `tcpdump`, and this was my conclusion:

> A big advantage of using DNS queries instead of HTTP queries is bandwidth: querying ns-aws.sslip.io requires a mere 592 bytes spread over 2 packets; Querying https://icanhazip.com/ requires 8692 bytes spread out over 34 packets—over 14 times as much! Admittedly bandwidth usage is a bigger concern for the one hosting the service than the one using the service.

(I had set up a service to determine your IP address via DNS, i.e. `dig @ns.sslip.io txt ip.sslip.io +short`, and measured why it was (marginally) better than using HTTP)

To be fair in the comparison; you can also query (via curl) icanhazip.com via HTTP instead of HTTPS, and it is only 5 packets and 385 bytes.

Good catch!

A couple decades ago I did SSH over DNS at the request of a client. It was pretty fun, worked surprisingly well. At the time, exactly zero firewalls stopped it.

I used to use iodine, a tunneling server which uses DNS as the transport, which would work even through captive portals at the time.

https://github.com/yarrick/iodine

ooh, MOSH over DNS. Theres all kinds of features to compensate for UDP lossiness built in.

Most tunnel protocols are UDP these days, vxlan, geneve, wireguard etc... Just because it doesn't guarantee delivery, meaning you don't get the retransmit amplification you'd get with TCP over TCP.

Why do you need to know the time in Paris while you're relaxing in a bunker at the bottom of the ocean? I know remote work is a thing now, but sheesh, some people just don't know how to disconnect ;)

> Although QUIC or TLS 1.3 improves that a bit.

On a TLS1.3 QUIC connection with a session supporting 0-rtt would DNS still require less round trips?

But you generally don't wanna keep a "connection" open to everyone in every scenario, like the one in the post.

You don't need a connection, you just need to have a session cached that you can resume. That's how 0-RTT works.

Well it depends very strongly on what you're doing. Looking at these packet sizes, on a 14.4 modem I'd expect the extra traffic to take about a second. But also you're waiting 10-20 seconds for HN to load or minutes for your average web page to load.

I came across "open" WiFis that required another form of login inside that filtered all HTTP traffic but let through DNS. But no, it's not really useful outside of special circumstances.

I have WireGuard endpoints of UDP 53, 443 and a high random port - at least one of them tends to work (although not always — one hotel recently only allowed tcp/80 and tcp/443

> one hotel recently only allowed tcp/80 and tcp/443

How did DNS resolution work? Do they force you to use their proxy server?

They could set up a recursive dnsmasq on the router, and block udp/53 traffic to the outside world.

This may work on pay to use Wi-Fi. There was a previous interesting post here about tunneling through DNS on airplane or other pay to use Wi-Fi.

https://news.ycombinator.com/item?id=511908

I have used this trick when I in high school grade.

Just setup openvpn with port 53 UDP with cheap vps, then connect it, and get unlimited internet access

Internet connection in my country is very limited and expensive in that day

You have no idea how badly I was looking for a way to tunnel via airplane wifi. Even going as far as trying to use the "free tier" fb messenger access to move packets. Now the ToS have a very low bandwidth limit on the free tier (eg. 100mb), so I'm not sure if it'd work for any real application.

I never thought to use DNS as a tunnel, but I have seen some pretty interesting loopholes that I was trying to find. Some airline's captive portal used to rely on some google service (captcha probs), and for a period of time didn't block any google-owned IP address that wasn't a consumer website (eg search, yt) so GCP and developer docs would load if you had the URL. I couldn't reliably get to user-generated content through it though.

> I never thought to use DNS as a tunnel

Most firewalls drop or hijack packets on port 53.

I have experienced this, i.e., hijacking, but I would respectfullly contest the term "most". But perhaps the statement was only referring to airports. I could be wrong but I like to think it is a minority of networks that hijack or block DNS. For example, a minority of consumer ISPs, other networks controlled by third parties (airports, hotels, etc.) or countries that conduct extremely aggressive internet censorship.

I can see the IP echo command be useful to verify if DNS traffic is routed differently than other traffic on a corporate network. Assuming outbound port 53 is not blocked completely on the network that is.

My default is the other way around, I'll question why something that is not a web page uses HTTP as an application-layer protocol when better fitted alternatives usually exist.

Add a bonus withering stare for assuming JSON is the only data serialization/interchange format.

maybe on a wifi network before authentication when it may allow DNS resolution but not HTTP requests?

Could you shuttle more data through this method to have a browser that works on unauthenticated captive portal wifi networks?

It's called dns tunnelling.

https://github.com/yarrick/iodine

looks like this can be used to get free wifi on airplane

> During the last decade, several types of software and malware used the DNS protocol for data exchange.

https://resources.infosecinstitute.com/topic/bypassing-secur...

That doesn’t mean the protocol isn’t useful for other purposes. Part of why it’s useful for the malware writers is that it’s highly available and often ignored by firewall rules.

That availability can also be used for good.

I can see using this on an isolated network of iot-like devices that don't quite have the guts or spare bandwidth for HTTPS. MQTT over DNS?

Maybe less likely to be blocked by some firewall policy?