How do I figure out where wrong local dns results are coming from?

I’m running mint Mate 17.2.

When I use dig, for a certain specific domain name, the resolved IP “answer” is wrong, and the answer server is 127.0.0.1.

Trying to access this domain from my local computer via ssh, a web browser, etc also resolves to the wrong IP.

DNS lookup using online tools or other computers works correctly.

Something on the local machine is intercepting the request and returning a wrong cached result. I have looked at various caching programs, but I don’t think I have any installed or configured any.

The IP address being returned is the old IP and the master DNS records were changed over a year ago.

How do I determine what program is intercepting DNS locally and disable it so I can have this domain resolve correctly on my computer?

/etc/resolv.conf:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1

Here is Solutions:

We have many solutions to this problem, But we recommend you to use the first solution because it is tested & true solution that will 100% work for you.

Solution 1

Resolvconf is pointing it out to a local software running in port 53 in the local machine.

To find it out which one:

sudo netstat -anlp | grep :53

As we have found out, it is the avahi daemon.

To trace DNS resolution, also following command is useful:

dig +trace www.cnn.com

If you want to control your DNS setting yourself, specially in server cases (I have notice you said Mint), I would recommend doing away with resolvconf

You can uninstall it with:

dpkg --purge resolvconf

Then, if you got the IP via DHCP leave it as it is, otherwise fill in your DNS servers in /etc/resolv.conf.

If you are not also interested in mDNS resolution or in a corporate network, I recommend uninstalling avahi.

In desktop settings, it maybe advisable either to reboot or restart all services. I would at least restart networking with service networking restart.

The Avahi mDNS/DNS-SD daemon implements Apple’s Zeroconf architecture
(also known as “Rendezvous” or “Bonjour”). The daemon registers local
IP addresses and static services using mDNS/DNS-SD and provides two
IPC APIs for local programs to make use of the mDNS record cache the
avahi-daemon maintains.

In a work setting, it maybe also be interesting following up at the network level servers/workstations which are announcing mDNS records, and if they are strictly necessary. I would bet some lost host file or some old server setting is propagating your old IP address via mDNS.

You may also listen in the local network mDNS packets with:

sudo tcpdump -n udp port 5353

From mDNS

The multicast Domain Name System (mDNS) resolves host names to IP
addresses within small networks that do not include a local name
server. It is a zero-configuration service, using essentially the same
programming interfaces, packet formats and operating semantics as the
unicast Domain Name System (DNS). Although Stuart Cheshire designed
mDNS to be stand-alone capable, it can work in concert with unicast
DNS servers.

Note: Use and implement solution 1 because this method fully tested our system.
Thank you 🙂

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

Leave a Reply