Recently there was a message indicating that ISC is deprecating nslookup. Dan Bernstein who has written a suite of DNS programs [http://cr.yp.to/djbdns.html] had once written to the djbdns list about problems with nslookup. Enclosed is his message dig and Dan Bernstein's tools like dnsq are much better than nslookup Regards, Yusuf -- Yusuf Goolamabbas [EMAIL PROTECTED]
nslookup is doing several things wrong here: (1) Before doing what you tell it to do, nslookup tries a PTR query on the server's IP address, so that it can tell you the server's name, as if this information were more useful than the server name or IP address that you gave to nslookup in the first place. (2) When you specify a server on the command line, nslookup sends its silly PTR query to that server, unjustifiably assuming that the server will have the answer. Correct behavior would be to ask the local cache. (3) If the silly PTR query fails, nslookup aborts, and never does what you told it to do. This is one of the basic reasons that everyone recommends against nslookup as a debugging tool. If, for example, you try ``nslookup -type=soa com a.root-servers.net'' to find the SOA record for .com on a.root-servers.net, nslookup will choke. Use ``dnsq soa com a.root-servers.net'' to get the answer. > The difference between a.ns and b.ns is that the in-addr.arpa server for the > address of a.ns is running tinydns. The in-addr.arpa server for the address > of b.ns is running BIND. No. The difference is that your servers happen to know the PTR record for 6.52.88.207.in-addr.arpa, but not for 251.63.104.209.in-addr.arpa. I tried ``nslookup -type=any ticketmaster.com a.ns.ticketmaster.com'' from here and it choked, even after you moved a.ns back to BIND. Every server could add a PTR record to work around this nslookup bug, but that creates unnecessary administrative problems. It's easier to tell people to stop using buggy ISC software. ---Dan
