Are you running the stock SunOS 4.1.x nslookup and BIND 4.9.3 in -current?
   A default option for BIND 4.9.3 is not to allow inverse queries.  The SunOS
   nslookup uses an inverse query when it starts - hence the error message.  A
   fix is to build a new nslookup for the Sun from the BIND 4.9.3 sources.  I
   don't think that fixing the resolver routines is enough here as Sun's stock
   nslookup doesn't use them.  Also SunOS mount and rcp won't use the new
   shared resolver routines, as they are statically linked.  Yuch!

   J

   PS.  SunOS's nslookup will also do this with HPUX 9.0.x named after a few
   weeks because HP seem to ship a version with a hole that causes it to go
   gaga after some time.  More Yuck!

   PPS. Novell's Lan Workplace for DOS 4 uses inverse query too.  Bleargh!
   Who'd run vendor supplies OS's ...

Now, WHY are inverse queries not allowed by default?  Some sort of
security hole?  I mean, aren't inverse queries kind of necessary?
I certainly want to find out who the hell 223.255.254.254 is if they're
trying to log on to my machine!

It's gonna take a LONG time for the rest of the world to catch up to
that change.  Don't believe me?  Look at how many places still make use
of inverse queries!

NOTE:  I understand the phrase "inverse query" to mean "given IP address
A.B.C.D, query the server D.C.B.A.in-addr.arpa and return a name".  If
this is an incorrect assumption, kindly disregard this letter.

				--*greywolf;
--