My LinkedIn post about the article Five DNS client tools, and how to use them received good feedback with a lot of suggestions and alternatives to the tools presented. As that LinkedIn post ages, it may also become harder to find, so I thought I will summarise those contributions here. It’s three DNS tools that can be easily installed on any container running in kubernetes by unpacking a compressed archive and copying the program’s executable file to the container. In addition, “side-channel” techniques are also mentioned. Let’s see!
Installation
All the three tools presented in the article provide a compressed archive. Assuming we are dealing with Linux, the general recipe is:
- unpack the archive in a local temporary directory
- find the executable file for the tool
- copy it to the container using
kubectl cp - get a shell in the container
- ensure that the file is executable in the container using
chmod u+x filename - ensure that the file is either in your
PATH, or that you execute it from the directory you copied it in by means of the./filenamesyntax
Since this part is common to all the three, I won’t repeat it everywhere.
dog
Suggested by Ed Daniel.
dog has a nice colored output which may make the result of a query easier to understand when there is a lot of data. Allegedly, the program is also able to understand if your terminal doesn’t support colors and offer a black/white alternative. It can also output JSON, which can make the information easier to process by other tools.
You can download dog from github. The latest version is 0.1.0, released in November 2020.
Usage
Examples from github, refer to the github page for more information.
dog example.net Query a domain using default settings
dog example.net MX …looking up MX records instead
dog example.net MX @1.1.1.1 …using a specific nameserver instead
dog example.net MX @1.1.1.1 -T …using TCP rather than UDP
dog -q example.net -t MX -n 1.1.1.1 -T As above, but using explicit arguments
Installation
Use the provided ZIP package. Unpack it in a temporary directory in your computer. The dog binary is in the bin subdirectory. Apply the recipe at the beginning of this article.
doggo
Suggested by Ed Daniel.
doggo is a tool inspired by dog, written in go (hence doggo: dog + go). It shares some of dog‘s nice features, and adds more on its own. The output is also a bit different. It has a rich command-line help, and the information and examples on the github page are exhaustive.
doggo is in active development. You can download doggo from github. The latest version is 0.5.7, released in September.
Usage
You are welcome to check the extensive usage examples from the github page. I’ll just report the simplest examples as a reference:
$ doggo mrkaran.dev
NAME TYPE CLASS TTL ADDRESS NAMESERVER
mrkaran.dev. A IN 20s 13.250.205.9 127.0.0.1:53
mrkaran.dev. A IN 20s 206.189.89.118 127.0.0.1:53
$ doggo -t MX -n 9.9.9.9 github.com
NAME TYPE CLASS TTL ADDRESS NAMESERVER
github.com. MX IN 3600s 10 alt3.aspmx.l.google.com. 9.9.9.9:53
github.com. MX IN 3600s 5 alt1.aspmx.l.google.com. 9.9.9.9:53
github.com. MX IN 3600s 10 alt4.aspmx.l.google.com. 9.9.9.9:53
github.com. MX IN 3600s 5 alt2.aspmx.l.google.com. 9.9.9.9:53
github.com. MX IN 3600s 1 aspmx.l.google.com. 9.9.9.9:53
$ doggo -t MX -n 9.9.9.9 github.com
NAME TYPE CLASS TTL ADDRESS NAMESERVER
github.com. MX IN 3600s 10 alt3.aspmx.l.google.com. 9.9.9.9:53
github.com. MX IN 3600s 5 alt1.aspmx.l.google.com. 9.9.9.9:53
github.com. MX IN 3600s 10 alt4.aspmx.l.google.com. 9.9.9.9:53
github.com. MX IN 3600s 5 alt2.aspmx.l.google.com. 9.9.9.9:53
github.com. MX IN 3600s 1 aspmx.l.google.com. 9.9.9.9:53Installation
Download the Linux ZIP package and unpack it in a temporary directory: the doggo executable is right there. Apply the recipe at the beginning of this article.
q
No, it’s not a typo nor a mistake: there is actually a DNS tool called just q!
Suggested by Chris Buijs.
Compared with the other two tools, and the comparison is made by the Author of q himself, q is the most feature rich of all clients. If you are debugging very exotic DNS problem, this one could be your tool. If not, it can still be your Swiss knife for DNS debugging. q supports all of the nice things from dog and doggo, and then adds some more of its own: were you missing YAML output? Well, here you have it. Do you need to set some special flags to your DNS query? Here you can.
q is in active development. The latest version is 0.15.0 and was released just three hours before I started writing this article!
Usage
As before, I’ll report only the basic examples from the github page which, by the way, doesn’t contain many of them. There is also a demo hosted in ASCIInema, but not much more.
q example.com Lookup default records for a domain
q example.com MX SOA …or specify a list of typesq example.com MX @9.9.9.9 Query a specific server
q example.com MX @https://dns.quad9.net …over HTTPS (or TCP, TLS, QUIC, or ODoH)…
q @sdns://AgcAAAAAAAAAAAAHOS45LjkuOQA …or from a DNS Stampq example.com MX --format=raw Output in raw (dig) format
q example.com MX --format=json …or as JSON (or YAML)Installation
There are deb and rpm packages that can be installed with native tools in many different distributions. Or, you can download the tar.gz package and unpack it in a temporary directory: the q executable is right there. Apply the recipe at the beginning of this article.
The side channel
What happens if you don’t have tools on the container and you cannot install one in any way? There is still hope. Suggested by Danny Sauer, you can use a “side channel” solution. For example, you can use commands that are not designed for the case you have at hand, but they will return the information you are interested nonetheless:
often you’ll find that ping is installed, while the dnsutils aren’t. Even if a target doesn’t actually respond to ICMP echos, ping usually prints the IP to which the name resolves – and has the benefit of using gethostbyname probably the same way as the program which isn’t working. 🙂
As Danny suggests, this is true also for other cases:
Ping -r to replace the missing traceroute is also handy.
Danny also contributed a gist to the discussion, where he shows how you can work around missing commands on a very thin container. Basically, you use low level interfaces to manually gather the information that dedicated commands would otherwise gather and pretty print for you. It’s an incredibly interesting reading, and you will do yourself a big favour if you take five more minutes to read that gist! (this post is about to finish anyway).
I wrote up a related gist a few years ago, speaking of this. It shows examples of doing some typical ps and lsof stuff with just ls, cat, and maybe tr on files in /proc in a pretty restrictive container. I need to fix the spelling and punctuation errors now that I reread it, but the actual code is accurate. 😅
https://gist.github.com/dannysauer/022dde4cea0eb9baa64fa99299ca40f2
Thanks
I’ll take the opportunity to thank Ed, Chris, and Danny for taking the time to share information about their favourite tools. I’d also like to thank Aleksey for his comment and all those who reacted to the LinkedIn post. This all was much appreciated!
A sysadmin's logbook 