nslookup: Rumors of my death have been greatly exaggerated

I'm currently working through the Sun Learning Connection (on-line / web-based training) to review the curriculum for my Sun Certified Network Administrator (SCNA) update examination. I'm a big fan of Sun's web based training as a study tool because it has always done a great job of preparing me for my certifications.

One of the interesting pieces of content I passed through indicated that in Solaris 10 the nslookup command has been deprecated. Dig is now included in Solaris, and according to the WS-3002-S10 course, is the preferred tool for querying DNS information. I remember when this same fascination with dig sped through the Linux distributions I used to use as well. I would type "nslookup _____" and the OS would dutifully reply that I really ought to be using dig, but here's my reply. You know what? I don't need my OS to tell me what I want. I just need it to do what I ask.

Fortunately, despite the menacing overtone of this training curriculum's message, I have yet to find a warning message come out of my Solaris servers. Dig is indeed included in Solaris, which is a great thing. It is certainly a more detailed tool for diagnosing DNS queries, and I'm thrilled to see Solaris inclusion of industry standard DNS tools.

But let's return once again to that hint about deprecating nslookup... Let's say I just want to see what the name service is returning for a given lookup. I'm just looking for right or wrong, not a detailed and cryptic report to gaze through. Here's the dig command and output for a reverse-lookup:

testbox# dig @192.168.1.2 foo.edu -x 192.168.2.1

; <<>> DiG 9.2.4 <<>> @192.168.1.2 two.edu -x 192.168.2.1
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1174
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0


;; QUESTION SECTION:
;two.foo. IN A

;; AUTHORITY SECTION:
foo.edu. 10800 IN SOA sys22.foo.edu.
root.sys22.foo.edu. 2005010101 3600 1800 6048000 86400


;; Query time: 11 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 08:07:30 2005
;; MSG SIZE rcvd: 72


;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR,
id: 1982
;; flags: qr rd ra; QUERY: 1, ANSWER: 1,
AUTHORITY: 2, ADDITIONAL: 0


;; QUESTION SECTION:
;1.2.168.192.in-addr.arpa. IN PTR


;; ANSWER SECTION:
1.2.168.192.in-addr.arpa. 86400 IN PTR sys21.foo.edu.

;; AUTHORITY SECTION:
2.168.192.in-addr.arpa. 86400 IN NS sys23.foo.edu.
2.168.192.in-addr.arpa. 86400 IN NS sys22.foo.edu.


;; Query time: 6 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 08:07:30 2005
;; MSG SIZE rcvd: 109


Whoa. That was a lot to digest. Now, REALLY QUICK... Go find out what the hostname is for the queried IP. Yeah, sorry, you took too long tracing through all that. Now lets' look at the nslookup approach:

testbox# nslookup 192.168.2.1
Server: 192.168.2.1
Address: 192.168.2.1#53

1.2.168.192.in-addr.arpa name = sys22.foo.edu.


Yep, that's a bit more efficient.

The moral of the story is that UNIX includes many tools, each of which serves a specific purpose it is (usually) optimized for. I'd hate to think that my future basic DNS queries would be serviced by unwieldy dig output. I'm thrilled that if I run into a more serious DNS issue I can call on dig to help me, but replacing nslookup completely with dig would be like replacing gEdit with OpenOffice Writer. The completely wrong philosophy.

To borrow from Mark Twain, "The rumours of nslookup's death are greatly exaggerated!"

Setting Terminal Title

Now that I'm spending a lot of time working on zones I've found myself needing to keep my desktop better organized so I can quickly find the zone and host I need amongst a slew of terminals. I like to keep things simple, so I went with a little shell script that sets the title of a window on demand. Here's what I ended up with:

if [ -x /bin/zonename ]; then
# if we are on a box that supports zones, include zone info in title
/bin/echo "\033]0;`/bin/hostname` [`/bin/zonename`]\007\c"
else
# handle non-zone platforms by omitting the zone name
/bin/echo "\033]0;`/bin/hostname`\007\c"
fi


This will update the gnome-terminal, or xterm title bar with "hostname [zonename]" on a platform that supports zones (as determined by the presence and executable attribute of /bin/zonename). If a host does not have that executable available and executable (such as pre-Solaris 10) it will simply print the hostname.

True to traditional UNIX' abbreviated nature I named the script stt, short for "set terminal title" and placed in my $HOME/bin directory for convenience. Now when I log in to a host, if I'll be in there for a while I just type 'stt' and my window is properly adorned.

A simple extension of this script would be to include the function in a shell's profile and inject it into the PS1 variable so that it is executed after each command. This would allow the title to update dynamically with each command. Haven't messed with that approach yet as this has scratched my itch quite well.