Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

All my queries on one machine on my network have suddenly started to resolve to 192.168.1.251.

This machine was used as the DNS server by other machines, so I noticed it as soon as it started happening and have switched all other machines to use 8.8.8.8 directly, which works.

The machines are all on a 192.168.0.x IP.

It does run dnsmasq, which I've restarted to no effect and so stopped, again, no difference.

/etc/resolv.conf did have entries for 127.0.0.1 and the router's IP, I've changed it to just contain one for 8.8.8.8 and there's nothing in /etc/hosts for a 192.168.1.251 IP.

Any ideas would be appreciated!

$ dig google.co.uk @8.8.8.8

; <<>> DiG 9.7.0-P1 <<>> google.co.uk @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49227
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.co.uk.          IN  A

;; ANSWER SECTION:
google.co.uk.       0   IN  A   192.168.1.251

;; Query time: 0 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Jan  6 20:22:03 2011
;; MSG SIZE  rcvd: 46


$ uname -a
Linux america 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686 GNU/Linux

Edit: This seemed to start working without any sign of any changes having effected the behaviour. I'm still none the wiser, but including the files below for completeness (and in case it comes back!)

$ cat /etc/hosts
127.0.0.1   localhost
127.0.0.1   america

192.168.0.1 england
192.168.0.2 america
192.168.0.3 germany
192.168.0.4 france
192.168.0.5 sweden

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

$ cat /etc/resolv.conf 
# Generated by NetworkManager
#nameserver 127.0.0.1
nameserver 8.8.8.8
#nameserver 4.2.2.2

$ cat /etc/nsswitch.conf 
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination  
share|improve this question
    
Is that your router's IP? –  Falmarri Jan 6 '11 at 20:52
    
No, all machines on the network are of the form 192.168.0.x. The router is at 192.168.0.1. –  rich Jan 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 Jorgensen Jan 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

up vote 2 down vote accepted

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.

share|improve this answer
    
I don't have any Windows boxes - I do have a NetGear WNCE2001 which this connects though though. Yet I can browse to IP addresses in and outside my network. –  rich Feb 7 '12 at 19:12
    
I think it's the WNCE2001. Pressed the button on it and the one on the router a few times and it's behaving now. Weird though. –  rich Feb 7 '12 at 19:29
    
I've found that giving the WNCE2001 boxes static IPs seems to prevent this happening, fortunately. –  rich Nov 29 '12 at 20:42

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.

Here the page which describes some of the behavior: http://bangbangsoundslikemachinery.blogspot.com/2011/10/anatomy-of-netgear-wnce2001-wireless.html

share|improve this answer

You're on a wifi hotspot and you haven't "agreed to the terms"?

share|improve this answer
    
I'm at home. On my own 192.168.0 network. –  rich Feb 7 '12 at 19:12

One possible explanation could be iptables + dnsmasq (or other nameserver) gone rogue.

  • bind, dnsmasq, some other nameserver are running locally replying 192.168.1.251 to everything you ask of it.
  • iptables rewrites outgoing packets on udp port 53 to end up somewhere locally where silly nameserver listens/ansers

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

So, I'd check if there's anything in the OUTPUT chain of the nat table redirecting dns traffic somewhere it shouldn't go ? (iptables -t nat -n -v -L OUTPUT).

You can reproduce this behavior with something along the lines of:

$ dnsmasq -p 5353 -A /#/192.168.1.251
$ iptables -t nat -I OUTPUT 1 -p udp --dport 53 -j REDIRECT --to-port 5353
# All locally generated requests outbound on udp port 53 gets sent to
# dnsmasq running on port 5353 which'll answer 192.168.1.251 to pretty much
# everything
$ dig @8.8.8.8 google.co.uk

; <<>> DiG 9.7.1-P2 <<>> @8.8.8.8 google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9993
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.co.uk.                  IN      A

;; ANSWER SECTION:
google.co.uk.           0       IN      A       192.168.1.251

;; Query time: 0 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jan 11 01:09:01 2011
;; MSG SIZE  rcvd: 46
share|improve this answer
    
I've just had it again. iptables -L shows there aren't any rules setup. –  rich Feb 7 '12 at 19:10

Wild guess: Inappropriate wildcard DNS? In the root hints?

* 3600 IN A 192.168.1.251
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.