Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: "q", a DNS query tool with support for UDP, TCP, DoT, DoH, DoQ and ODoH (github.com/natesales)
140 points by natesales on April 17, 2022 | hide | past | favorite | 45 comments



See also "dog" which I've been using for a while, works well. https://github.com/ogham/dog

I actually already have a "q" alias, I think single-letter aliases are probably quite common. Are there many other well-known utilities with a single-letter name?

Edit: Turns out I have one installed, "z", a universal archiver front-end. https://legacy.cs.indiana.edu/~kinzler/z/


I use a “z” as well, but it’s a global cd tool. https://github.com/rupa/z/


I use Zoxide[0], which incidentally also uses "z" as its main command, and it's also a "cd" tool.

[0]: https://github.com/ajeetdsouza/zoxide


> Are there many other well-known utilities with a single-letter name?

There is a `w` command. It's kind of like a mix of `who` and `uptime`.

https://linux.die.net/man/1/w


Huh! Today I learned that w and who aren't the same. I always thought they were.


The `w` command is more of a `what` instead of `who`.


It would seem that the project is stalled, if not dead.

I discovered the project with this thread and I was about to file a bug report when I saw some comments about the maintainer who went silent a year ago or so.


I use doggo, a better version written in Go: https://github.com/mr-karan/doggo


Grr.. the latest dog binary release gives me "GLIBC_2.32 not found" errors on x64 Linux..


A version might be on your repo - it's in the Homebrew repo on Macs.


also “y”, careful where you try it


It definitely makes sense for me to reserve 1-letter commands for the user.


I have n, a node version manager.


X


9k stars and 5yrs old: https://github.com/harelba/q

Why not call it like dnsq or dq like jq (https://stedolan.github.io/jq/) did?


You can’t just claim a letter and expect no one else to ever make a thing that is named that letter. Except C.


From a trademark perspective, that is exactly how it works: https://www.uspto.gov/trademarks/laws/dates-use-1

From a "I can only have one cli alias to q" perspective, then I am sticking with SQL "q" cmd, b/c its more useful and I have been using it longer than this one.


I use a lot of single-letter aliases, so I'd really prefer applications avoid using single-letter names, and reverse that specifically for user-local aliases.


There's already a thing called `dnsq`, it's part of the djbdns suite (along with dnsqr for recursive queries).

I actually miss it, now that pretty much all of djb's tools have fallen out of both fashion and maintenance, it was a much better -- and simpler -- tool than dig or nslookup.


Let me agree with the comments so far: Cool tool, not cool enough to take a 1-char name by default.


can you PLEASE use a longer word? this is hard to google and bad in an environment. everyone can abbreviate it with their shell if they want to.

at least the go people started calling the language golang. for heavens sake.


I like that we can generate a unique searchable phrase by the simple trick of pairing a term with its hypernym.

"qdnsquerytool"


Agree with others about the name, but I have a suggestion. There (surprisingly!) doesn't seem to be any *nix utility called `qed` so why not go with that?

Maybe standing for "query extended dns" or something. You can also riff on "The best DNS query tool by far. QED." and things of that nature.

Best grab it before someone else does.


Because the “Ed” suffix suggests editor?


Could be useful, but not _that_ useful for me to consider polluting my global shell namespace with this name.


What do you anticipate being the problem? I have several single-letter commands myself.


I already have a `q`, and frankly it's useful to me, so this piece of software will never be called `q` on any of my systems.

I suspect a lot of people have locked up all the single-letter aliases too, and I believe almost all of them would have the same position.

There's other tools for doing DNS diagnostics that are already installed on every system in the world. If I learn this one, I will have to take responsibility for maintaining the fact that I have to give it another name, and distribute that to other systems -- I won't be able to use this tool in a script, because I'll have to make sure the name is configurable for everyone else just like me.

Now I will not even give this software a chance because all of that seems so obvious to me, and the cuteness of the name such a display of fetishism (which usually detracts from quality in my experience) has me starting with an extremely low opinion and I haven't even made it to the github page yet. This software would have to be really good to overcome that. Is it?

I anticipate that being the big problem with choosing such a high-value single-letter name for something with such a narrow use-case. It just seems smarter to learn the tools that are already there. Heck, "c" can do everything and it doesn't even have the gall to do this; I think "cc" is a much better name, and whilst there are still a fair number of two-letter combinations that aren't used, I think I probably compile more C programs than do DNS diagnostics so maybe three or more letters would be better (if you buy the idea that huffman-coding your names is a good idea-- and I do)


Its probably pretty common to use q for one of those commands. It is also easy to accidentally enter an errant q into the shell.

Call it qdns?


IMHO, it should follow `jq`: `dnsq`: adjective noun


You are actively rooting against your tool/docs being discoverable by search engines, aren't you?


Interesting tool.

Though I'm not sure KDB+ users will be happy with the name.


Nice tool and nice interface. It's a shame that (and to no one's fault) we tend to rely on POSIX standard tools (or at least ones we can expect). I do it too since I like to know that that new machine I'm logged into has what I want. The big exception is for personal scripts where I'd only run them on my own machine since I have full control.

Very nice looking personal tool though.


I wrote dug, a cli tool I made to help visualize DNS propagation but is a great learning tool. Similar to dig and dog, but specifically for querying or watching large numbers of DNS servers at once.

https://github.com/unfrl/dug

https://dug.unfrl.com


Lots of nice little touches like the ttl in hms format, the --format=pretty/json/raw, etc. Bookmarking for later.


Can we talk about that name, though?

It only brings me associations with the Q-Anon movement.

Also, one-letter names is hard to google, hard to remember and easy to mix up.

If you want to use one letter on the CLI, just use an alias.

alias m=make


Very useful. Just built and installed with the Go tooling.

Friendly reminder: you can name the binary WHATEVER YOU WANT in your system. There's absolutely no need to nitpick on the name.


It's more about the discovery on search engines than in my own system.


Nice, given `dog` seems to be stalled.

Why `q` over `doggo` btw?



This was my question: what's the benefit of using `q` over `doggo`? Both are in Go, both seem to give nice colourful results. I'd appreciate having some comparison.


Thanks!

Sorry if this seems obvious, but what is "DNS query tool" useful for?


The domain name system is a hierarchical database of records that computers use to associate names ("news.ycombinator.com") with an IP address where the corresponding server is listening for connections. It's like how the post office knows how to get to your house to deliver a letter given only your address. It's a map of addresses.

Computers query this system all of the time to figure out where they're going. It's helpful for people to be able to query this system too, if only to help themselves understand where the computers are going to go. People create these records, after all, not the computers that use them.


No support for dnscrypt, anonymized DNS and the ability to directly enter DNS stamps?


Nice work! convenient to use!~


kdig anyone?




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: