5 ms·

Simplicity / latency / efficiency - DNS typically just fires off one UDP packet (generally one IP packet & ethernet frame too) and then gets one back (hopefully

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 :)

SahAssar 4y ago
> 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?
- lillecarl 4y ago
  But you generally don't wanna keep a "connection" open to everyone in every scenario, like the one in the post.
  - SahAssar 4y ago
    You don't need a connection, you just need to have a session cached that you can resume. That's how 0-RTT works.
lazide 4y ago
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.
- dicknuckle 4y ago
  ooh, MOSH over DNS. Theres all kinds of features to compensate for UDP lossiness built in.
  - lillecarl 4y ago
    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.
- hug 4y ago
  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 https://github.com/yarrick/iodine
Dylan16807 4y ago
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.
solardev 4y ago
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 ;)
brian_cunnie 4y ago
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/ 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)
- aq9 4y ago
  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.
  - brian_cunnie 4y ago
    Good catch!

SahAssar 4y ago

> 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?

lillecarl 4y ago
But you generally don't wanna keep a "connection" open to everyone in every scenario, like the one in the post.
- SahAssar 4y ago
  You don't need a connection, you just need to have a session cached that you can resume. That's how 0-RTT works.

lazide 4y ago

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.

dicknuckle 4y ago
ooh, MOSH over DNS. Theres all kinds of features to compensate for UDP lossiness built in.
- lillecarl 4y ago
  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.
hug 4y ago
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 https://github.com/yarrick/iodine

Dylan16807 4y ago

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.

solardev 4y ago

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 ;)

brian_cunnie 4y ago

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/ 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)

aq9 4y ago
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.
- brian_cunnie 4y ago
  Good catch!