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.
DNS Toys
51–60 of 111 posts
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…
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…
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
#54Re: 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?
https://resources.infosecinstitute.com/topic/bypassing-secur...
Re: DNS Toys
#56“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
#57“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 availability can also be used for good.
Re: DNS Toys
#58Fun :). 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).
Re: DNS Toys
#59Re: 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?