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 194.100.46.2: 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
stock response:

  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
    distribution.

    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
  turned on.

The version of nslookup supplied by Sun is old enough to get tripped up
by this.

			---  Truck