This problem (bug) exists in 6.x series. I have a DNS server that resides at IP 10.0.0.1. Using a RHL 6.x series installation on another machine if I put 'nameserver 10.0.0.1' in the /etc/resolv.conf file, nslookup will not work. If I change that to say 192.168.100.1 or even 10.2.2.1, it works. Since 10.0.0.1 is my firewall, default route, DNS server, etc. this is rather a PIA. :) Thanks, Chad
It sounds like there is no reverse DNS for 10.0.0.1. I'm changing the category to "bind" because nslookup is part of the "bind-utils" package. ------- Additional Comments From 10/25/99 19:03 ------- I fail to see how not having a in-addr.arpa entry makes a difference. You are correct there is no reverse entry for 10.0.0.1, BUT one would need connectivity to the dns server to find that out. When one uses nslookup it should connect to the IP address listed in /etc/resolv.conf, which when defined as 10.0.0.1, nslookup refuses to do. Ping, ssh, telnet, ftp, http, etc. all work to 10.0.0.1, so the IP setup is correct. The problem appears to be isolated to nslookup, though I suppose dig might also have problems, I've not checked.
I fail to see how not having a in-addr.arpa entry makes a difference. You are correct there is no reverse entry for 10.0.0.1, BUT one would need connectivity to the dns server to find that out. When one uses nslookup it should connect to the IP address listed in /etc/resolv.conf, which when defined as 10.0.0.1, nslookup refuses to do. Ping, ssh, telnet, ftp, http, etc. all work to 10.0.0.1, so the IP setup is correct. The problem appears to be isolated to nslookup, though I suppose dig might also have problems, I've not checked.