Subject: Re: name server problem NetBSD-current/stunos
To: Jukka Marin <email@example.com>
From: Don Lewis <firstname.lastname@example.org>
Date: 04/28/1996 22:48:50
On Apr 28, 10:19pm, Jukka Marin wrote:
} Subject: name server problem NetBSD-current/stunos
} 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 184.108.40.206: 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.
This question is frequently asked on the BIND mailing list. Here's my
From the README file in the BIND distribution:
Versions of NSLOOKUP up through BIND 4.8.3's used IQUERY to ask the local
server for information about the server's own name. I assume that this was
done in a "what the heck, nothing uses these, how can we contrive a need?"
sort of spirit. I removed this code as of BIND 4.9's NSLOOKUP and had it
use the standard gethostbyaddr() mechanisms (which depend on normal queries
of PTR data). Disabling INVQ and putting "options fake-iquery" in the boot
file will cause IQUERY to be answered bogusly but in a way that old nslookup
programs won't trip on. INVQ is disabled by default in conf/options.h.
Your options are:
Add "options fake-iquery" to named.boot and restart the server
Replace your old, broken nslookup with the one in the 4.9.3 BIND
Enable INVQ in conf/options.h, then rebuild and re-install named.
The latter option isn't guaranteed to work. If you point an old
version of nslookup at a server, and the server either is not
authoritative for a zone containing the A RR matching the address
you are sending the query to, or if this A RR is not in it's cache,
then nslookup will still fail even if the server has the INVQ option
The version of nslookup supplied by Sun is old enough to get tripped up