Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DNS Toys

dns.toys

Post reply on HN
Print view View original

11–20 of 111 posts

Re: DNS Toys

#11

Post by AdrianoKF »

pmoriarty wrote: post #10

I guess you could deliver web pages over DNS too, if you wanted... though I'm not sure why you'd want to. Instead of DoH it would be HoD.

You can also use iodine (https://github.com/yarrick/iodine/) to tunnel IPv4 data through DNS (useful e.g. when on a captive portal network that doesn't block DNS requests). Performance isn't great obviously, but the concept is fascinating nonetheless.

Re: DNS Toys

#12

Post by awill »

This is great. It's especially useful if you're already in a terminal. No special tools needed.

Re: DNS Toys

#13

Post by pinato »

Waterluvian wrote: post #4

“Why? For fun.” I love this. It doesn’t need a reason to exist. It’s interesting on its own. That being said, can anyone think of additional interesting reasons for why this would be useful rather than the same toys over HTTP?

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.

Re: DNS Toys

#14

Post by gpmcadam »

Waterluvian wrote: post #4

“Why? For fun.” I love this. It doesn’t need a reason to exist. It’s interesting on its own. That being said, can anyone think of additional interesting reasons for why this would be useful rather than the same toys over HTTP?

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

Re: DNS Toys

#16

Post by QuadrupleA »

Waterluvian wrote: post #4

“Why? For fun.” I love this. It doesn’t need a reason to exist. It’s interesting on its own. That being said, can anyone think of additional interesting reasons for why this would be useful rather than the same toys over HTTP?

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

Re: DNS Toys

#17

Post by [deleted] »

Waterluvian wrote: post #4

“Why? For fun.” I love this. It doesn’t need a reason to exist. It’s interesting on its own. That being said, can anyone think of additional interesting reasons for why this would be useful rather than the same toys over HTTP?

[deleted]

Re: DNS Toys

#18

Post by SahAssar »

QuadrupleA wrote: post #16
Waterluvian wrote: post #4

“Why? For fun.” I love this. It doesn’t need a reason to exist. It’s interesting on its own. That being said, can anyone think of additional interesting reasons for why this would be useful rather than the same toys over HTTP?

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 Anyway if you're using a 14.4 modem in a rusty bunker at the bot…

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

Re: DNS Toys

#19

Post by CAPSLOCKSSTUCK »

Fun :). It would be interesting to see how accurate one could get the time records (I see a TTL of 1 second, but what if the algorithm for reporting the time could try to measure latency between DNS client and itself and . . . yadda yadda yadda). Wish we had more submissions like this one.
Post reply on HN