Live data from Hacker News

DNS Toys

dns.toys

51–60 of 111 posts

Re: DNS Toys

#51
This is a fun tool, but it has some assumptions around IPv4.

It appears to work by responding with TXT records when given a query for A records. I have a `.digrc` file setup to query for AAAA records by default (since I mostly deal with IPv6 only networks). So I have to set the query for either A or TXT. Unfortunately, AAAA doesn't get the special treatment that A gets.

Re: DNS Toys

#52

“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…

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

Re: DNS Toys

#53

“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…

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)

Re: DNS Toys

#54
post #31

Earlier quoted context omitted.

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

Re: DNS Toys

#55

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

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

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

Re: DNS Toys

#56
post #13

“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.

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

Re: DNS Toys

#57
post #55

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

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

Re: DNS Toys

#58
post #24

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.

The TTL doesn't really matter in this case because you query the dns.toys DNS server directly, rather than going through a remote recursive resolver (which would normally cache any results it gets based on the TTL).

Will a local stub resolver respect the TTL, or are queries to authoritative name servers never cached? I know something like dnsproxy would care about the TTL, but not sure about, say, systemd-resolved. But good point nonetheless.

Re: DNS Toys

#60

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

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

Post reply on HN