Dig/NSLookup works ... ping doesn't ... but, it used to

sundialsvcs · 06-10-2016, 10:03 AM

(This is actually occurring on OS/X, and I see other threads on this same problem elsewhere.)

After a strange glitch with a DNS-server on our network, the ping command returns "Unknown Host," but the dig (or nslookup) commands promptly produce a NOERROR response from the server.

The "/etc/resolv.conf" file shows the intended DNS server first on the list, and "127.0.0.1" last. (I added 127.0.0.1, in response to another thread, but it didn't help.)

Even after rebooting the OS/X box, the problem still remains. (I even restarted the wireless router!)

But, it also appears to be inconsistent, as though there's some amount of caching going on somewhere. For instance, as I write this, "now, it has begun to work." I need to understand why the responses could be different. What is ping (and curl, and Firefox) looking at ... that produces a different answer?

dig output looks something like this:

Code:

; <<>> DiG 9.8.3-P1 <<>> somedomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36583
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;somedomain.com.		IN	A

;; ANSWER SECTION:
somedomain.com.	0	IN	A	111.222.111.222

;; Query time: 49 msec
;; SERVER: 11.55.44.33#53(11.55.44.33)
;; WHEN: Fri Jun 10 11:01:00 2016
;; MSG SIZE  rcvd: 52

dijetlo · 06-10-2016, 10:48 AM

Internmittent issue sounds like network. Try adding +trace to your DNS request and see if the resolution of your request is being offloaded to another zone. That would create a condition where your DNS server wont know who the target of a ping is (unless it's set to do recursive searches for ping packets and I'm thinking probably not...) however when pressed it can produce a record.
The other thing you can try is to do some TCP pings, there may be a problem with UDP routing in your network.

lazydog · 06-10-2016, 12:40 PM

Looking at your DIG output I'm not seeing a TTL on that record. Was thinking if the TTL is a long time you are getting a cached return on the DIG command thus DIG will work when the ping does not.

So what you are pining is it local or on the internet? Can you ping google.com?

jefro · 06-11-2016, 06:57 PM

Never heard of using localhost as a resolver. The local modem maybe but never localhost.

Different programs use a set of rules to decide how to resolve a name to ip. You can set that manually but I believe there is 4 steps that a browser uses for name lookup.

I frown on ping as a tool. It is being more and more a useless tool.
What does ip or ifconfig produce.

Anyway, you can try to access next upstream device like modem or router.

sundialsvcs · 06-12-2016, 03:23 PM

The DNS is "dnsmasq" which is serving entries from a hosts-file. I believe that TTL=0 in those cases.

There are no problems connecting to or pinging other sites. All sites mentioned in the host file or DNS output are available.

Here is the output of dig +trace somedomain.com and there is more there than I expected:

Code:

dig +trace www.signmojo.cloud

; <<>> DiG 9.8.3-P1 <<>> +trace somedomain.com
;; global options: +cmd
.			1593	IN	NS	g.root-servers.net.
.			1593	IN	NS	e.root-servers.net.
.			1593	IN	NS	b.root-servers.net.
.			1593	IN	NS	j.root-servers.net.
.			1593	IN	NS	a.root-servers.net.
.			1593	IN	NS	l.root-servers.net.
.			1593	IN	NS	d.root-servers.net.
.			1593	IN	NS	k.root-servers.net.
.			1593	IN	NS	h.root-servers.net.
.			1593	IN	NS	i.root-servers.net.
.			1593	IN	NS	c.root-servers.net.
.			1593	IN	NS	f.root-servers.net.
.			1593	IN	NS	m.root-servers.net.
;; Received 228 bytes from 111.222.111.222#53(111.222.111.222) in 695 ms

cloud.			172800	IN	NS	a.nic.cloud.
cloud.			172800	IN	NS	b.nic.cloud.
cloud.			172800	IN	NS	c.nic.cloud.
cloud.			172800	IN	NS	d.nic.cloud.
;; Received 280 bytes from 199.7.83.42#53(199.7.83.42) in 631 ms

cloud.			900	IN	SOA	a.nic.cloud. support.ariservices.com. 1465762319 1800 300 1814400 1800
;; Received 101 bytes from 37.209.196.10#53(37.209.196.10) in 64 ms

I don't know why "dig" received bytes from three servers, two of whom are unknown to me and which I did not expect to be consulted or talked-to.

sundialsvcs · 06-12-2016, 03:43 PM

Important Observation: After I posted the above comments ... and otherwise spent "about 10 minutes" doing other things ... it worked.

So, there is obviously some kind of timeout involved here . . .

- - - -

And then, after working(!), it stopped.

- - - -

"Curioser and curioser ..."

sundialsvcs · 06-13-2016, 08:51 AM

Another update:

The last reply to the original posting in this superuser.com thread lead me to this (OS/X-specific) magic incantation: sudo killall -HUP mDNSResponder, which did resolve the immediate problem.

Therefore, I have the following follow-on question . . .

It appears that incorrect DNS information is somehow being cached, and used for ordinary lookups. How might that "incorrect information" have gotten there? Based on the log-output in my previous post (in which three IP-addresses were contacted for some reason), I now can't be sure that the incorrect information actually came from my dnsmasq server, as I would have expected it to. But I urgently need to figure out what is going wrong (in any operating-system), so that this situation cannot happen.

Right now, dnsmasq appears to be operating as "the" name-server for the host upon which it is running, which obliges me to list (Google) name-servers as things to listen-to, although I have attempted to specify to dnsmasq that ".cloud" domains are to be served only by hosts-files.

sundialsvcs · 06-15-2016, 06:21 AM

The problem is definitely mDNSResponder, which is part of Apple's "Bonjour" zero-configuration networking system but also used by many other applications (Linux, Windows, and Mac) such as Skype.

Therefore, I really do need to know what to do about this. I don't really know why mDNSResponder decides that "blah-blah.cloud" does not exist, and why it never changes its mind ... even across sleep/restart ... until I send it a HUP signal. I've got a DNS that can provide the answer, but it looks like my Mac simply stops asking and decides that it already knows.

(This is a Multicast DNS service . . . Possibly-relevant voodoo includes:

Quote:

When an mDNS client needs to resolve a host name, it sends an IP multicast query message that asks the host having that name to identify itself. That target machine then multicasts a message that includes its IP address. All machines in that subnet can then use that information to update their mDNS caches.

Any host can relinquish its claim to a domain name by sending a response packet with a time to live (TTL) equal to zero.

By default, mDNS only and exclusively resolves host names ending with the .local top-level domain (TLD). This can cause problems if that domain includes hosts which do not implement mDNS but which can be found via a conventional unicast DNS server. Resolving such conflicts requires network-configuration changes that violate the zero-configuration goal.

Do I need to be using a different DNS mechanism now?

(Opening up a new thread on "Avahi" ...)