I used the BSD version of this (which seems the same AFAICT) a few times years ago and managed to misunderstand the output a few times and gave up. I doubt it was an actual error in the conversion but the UI is comically bad. The typical search engine UI is great, ask for a conversion using whatever abbreviations you want and it gives you a detailed explanation of what it thinks you asked for and the result (and not some other number you didn't ask for). I see GNU units at least has a -1 option to just give the result.
Firefox has a hidden simple unit conversion tool that can be enabled by setting browser.urlbar.unitConversion.enabled to true. It only has a few conversions, though, and doesn't give much detail about what it thinks you asked for.
It looks like there is a rust unit conversion utility called rink that seems better although, like many rust utilities, it lacks a man page or any local documentation besides a brief --help message (there is an online manual). Some units are a bit annoying; you can't just do c to f, only degC to degF (and not even degc to degf either). But much nicer than units and can also be easily be used as an interactive calculator.
Edit: Playing around with rink a bit more it has some neat stuff. It gives info if you enter a unit (or constant or substance), usually defined in terms of the base unit of each type but if you give the base unit it has a brief text explaining how the base unit is defined. "c to f" not working is because it doesn't use context and c is the speed of light. You can use 'units for' to see available units for a particular type, although it doesn't look like you can show all available units other than checking the source (based on the GNU units definitions but with some differences, such as degC). It suggests a supported unit if you type one it doesn't understand.
This can be combined with unit conversion of course:
units -t '(8 lbf) / (9.8 m/s^2)' slug
Be careful using it for temperature conversion. You need to use tempC and tempF functions, not degC and degF units, because of the linear offset from absolute zero.
Correct way (absolute temperature):
units -t 'tempF(71)' tempC
Incorrect way (temperature difference):
units -t '71 degF' degC
I use units a ton, so I have the following in my .zshrc:
# in-terminal calculator: e.g. `calc 60 * 60 * 4`
_calc () {
units -t "$*"
}
alias calc='noglob _calc'
# units convenience, use ( and * without quoting
alias u='noglob units -t'
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
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 :)
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.
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.
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.
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 ;)
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)
I can see the IP echo command be useful to verify if DNS traffic is routed differently than other traffic on a corporate network.
Assuming outbound port 53 is not blocked completely on the network that is.
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.
You have no idea how badly I was looking for a way to tunnel via airplane wifi. Even going as far as trying to use the "free tier" fb messenger access to move packets. Now the ToS have a very low bandwidth limit on the free tier (eg. 100mb), so I'm not sure if it'd work for any real application.
I never thought to use DNS as a tunnel, but I have seen some pretty interesting loopholes that I was trying to find. Some airline's captive portal used to rely on some google service (captcha probs), and for a period of time didn't block any google-owned IP address that wasn't a consumer website (eg search, yt) so GCP and developer docs would load if you had the URL. I couldn't reliably get to user-generated content through it though.
I have experienced this, i.e., hijacking, but I would respectfullly contest the term "most". But perhaps the statement was only referring to airports. I could be wrong but I like to think it is a minority of networks that hijack or block DNS. For example, a minority of consumer ISPs, other networks controlled by third parties (airports, hotels, etc.) or countries that conduct extremely aggressive internet censorship.
My default is the other way around, I'll question why something that is not a web page uses HTTP as an application-layer protocol when better fitted alternatives usually exist.
Add a bonus withering stare for assuming JSON is the only data serialization/interchange format.
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.
I experimented with this over 10 years ago. I used a modified dnstxt from djbdns and put MIME headers and HTML into TXT RRs. tinydns allows a wider variety of bytes in RRs than other DNS software. At least, it was generally less restrictive than the other DNS software available at that time.
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.
Then you'd be at the mercy of caching in whatever recursive resolver is in between you and dns.toys. Sure, you can specify the TTL but if you give one to low many resolvers will ignore it and just make up their own.
DNS servers _usually_ reply with information about a queried domain name or a host name. dig is a command-line tool that queries a given name server (or a preset one) for that information. For example `dig news.ycombinator.com` returns the IP address of HN, and `dig news.ycombinator.com @example.com` queries the example.com nameserver for that domain.
dns.toys runs a DNS server that dynamically returns answers such as times, currency information, etc (instead of domain name information) if you format your query right.
So for example, `dig mumbai.time @dns.toys` returns the time in Mumbai in a DNS TXT record instead of an IP address (or an NXDOMAIN response, saying the domain does not exists).
Play around with the `dig` command, it is an intuitive tool that you will eventually use if you are a CS or a related Freshman.
Out of curiosity, I looked at the headers after clicking on your link and I found that it was sending Referrer as: https://news.ycombinator.com which is not an issue. But then I refreshed the page and saw the same Referrer again. So I checked where it was getting the Referrer from and it was not storing anything in localStorage, not in URL, nor in sessionStorage, nor in cookies. Any idea where the site was getting the Referrer from?
Yeah you're right. Selecting the URL and hitting enter did clear the Referer. One comment says the browser identifies the Referer by looking at the history is that so?
Referer [sic] is determined by your browser, not the site. If you just refreshed the tab then its probably looking at the history.
Also, no browser that wants to make any claim of caring about privacy should still be sending cross-domain Referer headers by default which is yet another reason why Mozilla's privacy marketing is just that: marketing without substance.
sic is used to highlight that a spelling or grammar mistake in your writing is part of a direct quote being provided unaltered, and not your own mistake.
It isn't used to provide corrections.
Anyway, both spellings are fine in various regions.
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. :)
110 comments
[ 2.0 ms ] story [ 174 ms ] threadFirefox has a hidden simple unit conversion tool that can be enabled by setting browser.urlbar.unitConversion.enabled to true. It only has a few conversions, though, and doesn't give much detail about what it thinks you asked for.
It looks like there is a rust unit conversion utility called rink that seems better although, like many rust utilities, it lacks a man page or any local documentation besides a brief --help message (there is an online manual). Some units are a bit annoying; you can't just do c to f, only degC to degF (and not even degc to degf either). But much nicer than units and can also be easily be used as an interactive calculator.
https://rinkcalc.app/
Edit: Playing around with rink a bit more it has some neat stuff. It gives info if you enter a unit (or constant or substance), usually defined in terms of the base unit of each type but if you give the base unit it has a brief text explaining how the base unit is defined. "c to f" not working is because it doesn't use context and c is the speed of light. You can use 'units for' to see available units for a particular type, although it doesn't look like you can show all available units other than checking the source (based on the GNU units definitions but with some differences, such as degC). It suggests a supported unit if you type one it doesn't understand.
Correct way (absolute temperature):
Incorrect way (temperature difference): I use units a ton, so I have the following in my .zshrc:$ dig seat2222tle.time @dns.toys +short "Seattle (America/Los_Angeles, US)" "Sat, 11 Jun 2022 08:22:42 -0700"
dig seattlr.time @dns.toys +short
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?
How did DNS resolution work? Do they force you to use their proxy server?
https://github.com/yarrick/iodine
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 :)
On a TLS1.3 QUIC connection with a session supporting 0-rtt would DNS still require less round trips?
https://github.com/yarrick/iodine
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)
https://resources.infosecinstitute.com/topic/bypassing-secur...
That availability can also be used for good.
https://news.ycombinator.com/item?id=511908
Just setup openvpn with port 53 UDP with cheap vps, then connect it, and get unlimited internet access
Internet connection in my country is very limited and expensive in that day
I never thought to use DNS as a tunnel, but I have seen some pretty interesting loopholes that I was trying to find. Some airline's captive portal used to rely on some google service (captcha probs), and for a period of time didn't block any google-owned IP address that wasn't a consumer website (eg search, yt) so GCP and developer docs would load if you had the URL. I couldn't reliably get to user-generated content through it though.
Most firewalls drop or hijack packets on port 53.
Add a bonus withering stare for assuming JSON is the only data serialization/interchange format.
Instead of DoH it would be HoD.
Eg.
dig newyork.time.dns.toys with a low ttl?
This way folks operating in an environment where they can't egress on port 53 can still use the tools?
dns.toys runs a DNS server that dynamically returns answers such as times, currency information, etc (instead of domain name information) if you format your query right.
So for example, `dig mumbai.time @dns.toys` returns the time in Mumbai in a DNS TXT record instead of an IP address (or an NXDOMAIN response, saying the domain does not exists).
Play around with the `dig` command, it is an intuitive tool that you will eventually use if you are a CS or a related Freshman.
I see that dns.toys use it.
You'll notice this behavior goes away if you select the URL bar and hit enter (as if you were navigating to the site manually).
Also, no browser that wants to make any claim of caring about privacy should still be sending cross-domain Referer headers by default which is yet another reason why Mozilla's privacy marketing is just that: marketing without substance.
https://developer.yr.no/featured-products/forecast/
And furthermore, +short gives you the same multiple answers that +noall +answer +additional does, without the extra dns stuff that you don't need.