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

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 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 and the router's IP, I've changed it to just contain one for and there's nothing in /etc/hosts for a IP.

Any ideas would be appreciated!

$ dig google.co.uk @

; <<>> DiG 9.7.0-P1 <<>> google.co.uk @
;; 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

;google.co.uk.          IN  A

google.co.uk.       0   IN  A

;; Query time: 0 msec
;; 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   localhost   america england america germany france 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

$ 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  
  • Is that your router's IP?
    – Falmarri
    Jan 6, 2011 at 20:52
  • No, all machines on the network are of the form 192.168.0.x. The router is at
    – rich
    Jan 6, 2011 at 21:02
  • cat /etc/resolv.conf please, not that I don't trust you... but let's have the actual file. Jan 10, 2011 at 13:07
  • @xenoterracide with the @<ip> option to dig, dig goes directly to <ip> and ignore any nameservers listed in /etc/resolv.conf Jan 11, 2011 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? Jan 11, 2011 at 14:47

5 Answers 5


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


Good grief. I had this problem on one computer, finding that NetworkManager had put as a nameserver into /etc/resolv.conf even though my entire network is . 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 !! 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 ! 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" and found this site. This is the first site I checked out. I'm very curious. Will check a few other hits.

  • 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, 2012 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, 2012 at 19:29
  • I've found that giving the WNCE2001 boxes static IPs seems to prevent this happening, fortunately.
    – rich
    Nov 29, 2012 at 20:42

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

  • I'm at home. On my own 192.168.0 network.
    – rich
    Feb 7, 2012 at 19:12

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

  • bind, dnsmasq, some other nameserver are running locally replying 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, 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 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 intercepts and redirects dns queries and generates a bogus reply, however since your other machines on the same network with their resolver pointed to 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 /#/
$ 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 to pretty much
# everything
$ dig @ google.co.uk

; <<>> DiG 9.7.1-P2 <<>> @ 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

;google.co.uk.                  IN      A

google.co.uk.           0       IN      A

;; Query time: 0 msec
;; WHEN: Tue Jan 11 01:09:01 2011
;; MSG SIZE  rcvd: 46
  • I've just had it again. iptables -L shows there aren't any rules setup.
    – rich
    Feb 7, 2012 at 19:10

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

* 3600 IN A

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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