LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 06-10-2016, 10:03 AM   #1
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,635
Blog Entries: 4

Rep: Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931
Dig/NSLookup works ... ping doesn't ... but, it used to


(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

Last edited by sundialsvcs; 06-10-2016 at 10:04 AM.
 
Old 06-10-2016, 10:48 AM   #2
dijetlo
Senior Member
 
Registered: Jan 2009
Location: RHELtopia....
Distribution: Solaris 11.2/Slackware/RHEL/
Posts: 1,491
Blog Entries: 2

Rep: Reputation: Disabled
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.

Last edited by dijetlo; 06-10-2016 at 10:50 AM. Reason: Remembered the TCP pings
 
Old 06-10-2016, 12:40 PM   #3
lazydog
Senior Member
 
Registered: Dec 2003
Location: The Key Stone State
Distribution: CentOS Sabayon and now Gentoo
Posts: 1,249
Blog Entries: 3

Rep: Reputation: 194Reputation: 194
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?
 
Old 06-11-2016, 06:57 PM   #4
jefro
Moderator
 
Registered: Mar 2008
Posts: 21,970

Rep: Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622Reputation: 3622
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.
 
Old 06-12-2016, 03:23 PM   #5
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,635

Original Poster
Blog Entries: 4

Rep: Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931
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.

Last edited by sundialsvcs; 06-12-2016 at 03:28 PM.
 
Old 06-12-2016, 03:43 PM   #6
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,635

Original Poster
Blog Entries: 4

Rep: Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931
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 ..."

Last edited by sundialsvcs; 06-12-2016 at 03:45 PM.
 
Old 06-13-2016, 08:51 AM   #7
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,635

Original Poster
Blog Entries: 4

Rep: Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931
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.
 
Old 06-15-2016, 06:21 AM   #8
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,635

Original Poster
Blog Entries: 4

Rep: Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931
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" ...)

Last edited by sundialsvcs; 06-15-2016 at 06:31 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Inconsistent results using ping, dig, nslookup, whois, host steelaz Linux - Networking 3 04-05-2009 07:50 AM
nameserver resolves unqualified hostname in nslookup, ping (at CLI) doesn't-- why? lumix Linux - Networking 1 02-29-2008 07:23 PM
dig @ works, dig doesn't eelgueta Linux - Networking 6 07-09-2007 06:45 PM
nslookup works, ping doesn't coolnicklas Linux - Networking 5 04-16-2005 08:23 PM
DIG / NSLOOKUP message? matrx88 Linux - Networking 1 08-20-2003 12:15 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 01:22 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration