No, all machines on the network are of the form 192.168.0.x. The router is at 192.168.0.1.
–
richJan 6 '11 at 21:02

cat /etc/resolv.conf please, not that I don't trust you... but let's have the actual file.
–
xenoterracide♦Jan 10 '11 at 13:07

@xenoterracide with the @<ip> option to dig, dig goes directly to <ip> and ignore any nameservers listed in /etc/resolv.conf
–
Kjetil JorgensenJan 11 '11 at 14:40

@kjetil true, and I'll raise that a /etc/hosts and a /etc/nsswitch.conf. though I don't think dig uses any of that, but it certainly will speak loads of information about what the system is doing. and where's my dig +trace?
–
xenoterracide♦Jan 11 '11 at 14:47

5 Answers
5

Good grief. I had this problem on one computer, finding that NetworkManager had put 192.168.1.251 as a nameserver into /etc/resolv.conf even though my entire network is 192.168.0.0/24 . My guess had been that it had to do with the NetGear WNC2001 Wifi box I had plugged into the ethernet port of that Linux box. But then today, while working on Windows XP on a used T60p I just bought, I found that it had correctly gotten an IP address from my wireless router, but that it had set the DNS server to 192.168.1.251 !! No WNC2001 on this box. Seemed like a big coincidence that two totally different computers on my network would somehow incorrectly set their DNS server to 192.168.1.251 ! I did a "ipconfig /renew" on the Windows box and it correctly set the DNS servers to those given to it by my router (a D-Link DIR-628). I decided to look up "DNS 192.168.1.251" and found this site. This is the first site I checked out. I'm very curious. Will check a few other hits.

We're having similar issues at this coworking facility; one potential culprit is a Netgear WNCE2001 wireless transceiver, which (out of necessity) has an embedded DHCP server, but is only supposed to serve requests out to the wired link.

The manager had one misbehaving today and had to reconfigure it. Normally it bridges a Skype phone onto the wireless network here.

The reasoning behind this being:
You use dig to troubleshoot and instruct dig with the @ option to go directly to 8.8.8.8, dig should now ignore nameserver(s) listed in /etc/resolv.conf. As dig itself implements a resolver and generates queries itself, then sends it to 8.8.8.8 and parses/prints replies, this should eliminate anything funky in the configuration of libc's resolver on the box (which pretty much everything else uses).

This would suggest that:

google have misconfigured their nameservers to give you bogus replies, which is unlikely

something along the way between you and 8.8.8.8 intercepts and redirects dns queries and generates a bogus reply, however since your other machines on the same network with their resolver pointed to 8.8.8.8 gets sane results, this isn't likely either

something on this computer intercepts outbound DNS queries and directs them elsewhere which generates silly/wrong replies