Thursday, December 27, 2018

Back to Basics: Making nslookup more useful

As we forge ahead in to a brave new world or AI, ML, and AR, it's helpful to occasionally step back and consider some basic information technology skills that we should all possess. These are foundational skills that demonstrate functional understanding of IT principles. This post deals with one of the most basic tools in the administrator's kit: nslookup.

DNS is Everything

Thanks to DNS, we address our systems, sites, and services with human-reabable text. Without DNS, we'd be forced to recall the IP address of each system we want to connect with. Sure, you can probably memorize a few dozen /24s, but it's not practical to live without DNS. And it's always a reasonable suggestion to, when things on your network just went belly-up, check DNS. Because it's always DNS.

If ping is the first command junior IT admins learn, nslookup is a close second. And just like most IT admins are content to ping hostnames and IPs without ever looking into the richness of the command's syntax, nslookup's best tricks are reserved for those who want more from their query than a simple hostname or IP.

Before we get any farther, I'll note that for a short time nslookup was a deprecated utility. But the ISC reversed its course in 2004 and agreed to let nslookup soldier on. (Note change 1700 in the CHANGES log on the BIND 9.3 release page, which contains the all-business text that saved nslookup: nslookup is no longer to be treated as deprecated. Remove "deprecated" warning message. Add man page.).That's why you'll find it on every modern OS to this day (see this link for Microsoft's latest info on nslookup in Windows).

nslookup vs. dig

For starters, comparing these two utilities is like comparing an abacus to a TI-81: you wouldn't ever expect an abacus to produce a graph of the sine function. The same is true for nslookup: you wouldn't expect it to return a vast amount of information regarding a single host. dig is great at that.

But if you use Windows at work, and don't have access to dig, you can add a simple switch to your nslookup queries to make it return a wealth of dig-like responses for the most innocuous request.

The secret is to append -debug to your nslookup queries (if you're a one-at-at-time nslookup-er), or enter the nslookup utility with -debug for extended DNS query sessions. Instead of returning simple IP information for your hostname queries, nslookup will now return a whole host of information. That's a DNS joke. Yes, I'm sorry.

Making sense of this information will be covered in the next post in this series. In the meantime, nslookup -debug away!

Wednesday, June 20, 2018

vmkping Error: Unknown Interface

In the middle of troubleshooting an issue with vMotion traffic failing, I ran into an annoying issue with vmkping: attempting to specify certain vmkernel interfaces as the traffic source would throw an error like the one below.

What's annoying about this is vmk4 is not unknown. It's tagged for vMotion traffic.

After some googling, I learned that using a poorly-documented argument will allow vmkping to work properly. If you've run into this issue, add ++netstack=vmotion to your vmkping command. You'll get the results you were expecting the first time around.

Incidentally, if you've ever posted screenshots of your ESXi host's ssh session and blurred out the hostname for SECURITY purposes: don't do that. Instead, change the prompt by modifying /etc/profile.local. William Lam has a years-old post here (note that what he suggested years ago has been implemented as default config). Much cleaner presentation this way.