Live data from Hacker News

DNS Toys

dns.toys

91–100 of 111 posts

Re: DNS Toys

#91
post #13

Earlier quoted context omitted.

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?

Re: DNS Toys

#92
I love it!

I am not a DNS expert, but if one format for DNS queries is ., i.e., "mumbai.time", "berlin.weather" as seems to be the case -- then I think it would be interesting to see if a general-purpose query in this format -- could be passed along to a search engine, then get the result back from that, strip the HTML, and pass the resulting text back in the answer section...

Why?

Well, it could have emergency preparedness applications -- imagine that for whatever reason, all computers complex enough to run modern web browsers suddenly stopped working -- and all that still works are dumb terminals and mostly text-based computers from the 1980's...

In that scenario (and we hope it never happens!) -- it would be awesome, truly awesome, to have a way to still be able to query search engines and possibly other Internet services -- if most of the other infrastructure is no longer working.

It might also be possible to implement some type of rudimentary email system over this, as well...

Anyway, I think what you've done is absolutely brilliant!

Re: DNS Toys

#93
Interesting if "normal" (unrestricted) Internet connection. Fails if using a VPN solution (PIA and Mullvad, so far) - probably because they trap name resolution attempts, if forcing using their own.

Re: DNS Toys

#94

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

Re: DNS Toys

#95
Isn’t this sort of a continuation/improvement on the ancient single-purpose protocols and commands like `finger` or `ident` etc. but consolidated into a single port/command?

Maybe we could formalize this into a new protocol? Send some text, get some text back, with minimal overhead. Let’s call it “ask” or “q” (for query)

Re: DNS Toys

#97
post #48

Picky overcorrect comment: Try dig +short instead of dig +noall +answer +additional i.e. dig +short mumbai.time @dns.toys gives you the short and breve answer you probably expect :-)

Not quite, some queries have multiple records and multiple response fields, so it's necessary to do: dig +short london.time @dns.toys |head -n 1 |cut -d '"' -f4 In order to get clean time for a city, for example. At which point you'd be better learning the arguments to local tools. But anyway, cute hack and cool mountain-name. :)

You wouldn't use London.time in your query in a script though, because it returns multiple answers. You'd use London/gb or London/ca.time

And furthermore, +short gives you the same multiple answers that +noall +answer +additional does, without the extra dns stuff that you don't need.

Re: DNS Toys

#98

Really pleasing - though the most surprising thing was learning a forward slash is a valid character in a domain name. Are there any real world examples?

RFC 2317 (BCP 20) says to use it, but in my experience, everyone implementing this scheme uses a dash instead of a slash.
Post reply on HN