Subject: Re: name server problem NetBSD-current/stunos
To: Jukka Marin <email@example.com>
From: J.D.Coleman <J.D.Coleman@newcastle.ac.uk>
Date: 04/29/1996 09:50:25
> Dunno if I will get flamed for this, but I'm in trouble and....
> I have this NetBSD-current box which is our nameserver. It seems to work
> ok. I have installed a resolver fix on a sunos box. When I try to
> 'nslookup' on the sunos box, I get the following message:
> *** Can't find server name for address 126.96.36.199: Query refused
> This is my nameserver's address. The name is in /etc/hosts and in the
> server's database. After the message, nslookup dumps core.
> I didn't have this problem when using NetBSD 1.1 as a nameserver.
> Also, if I use NetBSD clients to make queries to the nameserver,
> everything works well.
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!
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 ...
"The Ravenous Bugblatter Beast of Traal! Is it safe?"
"Oh yes, it's perfectly safe. It's just us who are in trouble!"
Wargame (n): battle simulation using painted numbers.