Want to highlight a helpful answer? Upvote!

Did someone help you, or did an answer or User Tip resolve your issue? Upvote by selecting the upvote arrow. Your feedback helps others! Learn more about when to upvote >

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

User profile for user: MarkSapiro
MarkSapiro Author
User level: Level 1
0 points

Name service lookups fail - SnowLeopard

From time to time while browsing, I will get name service failures. For example, I may search for something at www.google.com, follow a few links, go back to the results and click another link and get

Firefox can't find the server at www.google.com.

even though I have just been to other non-cached www.google.com pages.

I have seen the forum threads

http://discussions.apple.com/thread.jspa?threadID=2140119

http://discussions.apple.com/thread.jspa?threadID=2200670

http://discussions.apple.com/thread.jspa?threadID=2159790

http://discussions.apple.com/thread.jspa?threadID=2132856

and tried some of the things there. I.e. I have switched from fixed DNS settings to using my router via DHCP, and I still see the problem.

When I see the problem, I can open terminal and ping the name and I get

ping: cannot resolve www.google.com: Unknown host

but if I dig the A record, it is there. Here's an example with this forum's web site - dig succeeds, ping fails, dig succeeds, ping fails:


Macintosh-2:~ msapiro$ dig discussions.apple.com

; <<>> DiG 9.6.0-APPLE-P2 <<>> discussions.apple.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24981
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 9, ADDITIONAL: 2

;; QUESTION SECTION:
;discussions.apple.com. IN A

;; ANSWER SECTION:
discussions.apple.com. 600 IN CNAME discussions.apple.com.edgesuite.net.
discussions.apple.com.edgesuite.net. 18717 IN CNAME a1399.b.akamai.net.
a1399.b.akamai.net. 20 IN A 66.51.197.168
a1399.b.akamai.net. 20 IN A 66.51.197.167

;; AUTHORITY SECTION:
b.akamai.net. 1800 IN NS n7b.akamai.net.
b.akamai.net. 1800 IN NS n8b.akamai.net.
b.akamai.net. 1800 IN NS n0b.akamai.net.
b.akamai.net. 1800 IN NS n1b.akamai.net.
b.akamai.net. 1800 IN NS n2b.akamai.net.
b.akamai.net. 1800 IN NS n3b.akamai.net.
b.akamai.net. 1800 IN NS n4b.akamai.net.
b.akamai.net. 1800 IN NS n5b.akamai.net.
b.akamai.net. 1800 IN NS n6b.akamai.net.

;; ADDITIONAL SECTION:
n5b.akamai.net. 719 IN A 66.51.197.165
n8b.akamai.net. 739 IN A 72.246.103.31

;; Query time: 333 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Tue Oct 27 14:10:43 2009
;; MSG SIZE rcvd: 343

Macintosh-2:~ msapiro$ ping discussions.apple.com
ping: cannot resolve discussions.apple.com: Unknown host
Macintosh-2:~ msapiro$ dig discussions.apple.com

; <<>> DiG 9.6.0-APPLE-P2 <<>> discussions.apple.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64284
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 9, ADDITIONAL: 2

;; QUESTION SECTION:
;discussions.apple.com. IN A

;; ANSWER SECTION:
discussions.apple.com. 548 IN CNAME discussions.apple.com.edgesuite.net.
discussions.apple.com.edgesuite.net. 18665 IN CNAME a1399.b.akamai.net.
a1399.b.akamai.net. 20 IN A 66.51.197.168
a1399.b.akamai.net. 20 IN A 66.51.197.167

;; AUTHORITY SECTION:
b.akamai.net. 1748 IN NS n5b.akamai.net.
b.akamai.net. 1748 IN NS n6b.akamai.net.
b.akamai.net. 1748 IN NS n7b.akamai.net.
b.akamai.net. 1748 IN NS n8b.akamai.net.
b.akamai.net. 1748 IN NS n0b.akamai.net.
b.akamai.net. 1748 IN NS n1b.akamai.net.
b.akamai.net. 1748 IN NS n2b.akamai.net.
b.akamai.net. 1748 IN NS n3b.akamai.net.
b.akamai.net. 1748 IN NS n4b.akamai.net.

;; ADDITIONAL SECTION:
n5b.akamai.net. 667 IN A 66.51.197.165
n8b.akamai.net. 687 IN A 72.246.103.31

;; Query time: 388 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Tue Oct 27 14:11:34 2009
;; MSG SIZE rcvd: 343

Macintosh-2:~ msapiro$ ping discussions.apple.com
ping: cannot resolve discussions.apple.com: Unknown host
Macintosh-2:~ msapiro$

This is a Wi-Fi WPA-shared key connection. when the problem occurs, I can at least sometimes fix it by disconnecting the airport and reconnecting. It started after I upgraded from Leopard.

iMac4,1, Mac OS X (10.6.1)

Posted on Oct 27, 2009 3:47 PM

Reply
5 replies
User profile for user: Dogcow-Moof
Dogcow-Moof
User level: Level 8
36,239 points

Oct 27, 2009 3:50 PM in response to MarkSapiro

dig and the balance of Mac OS X use two different methods of resolving names.

The most common reason for these issues is that your DHCP server or you manually have provided multiple DNS server addresses and one of them is failing to resolve queries properly.

There is an issue, currently unknown as to whether it's a bug or feature, where mDNSResponder will use provided DNS server entries in a somewhat round-robin order rather than in the order specified.

This has caused problems for many whose DNS servers are not equally qualified to resolve requests.
Reply
User profile for user: Dogcow-Moof
Dogcow-Moof
User level: Level 8
36,239 points

Oct 27, 2009 10:35 PM in response to MarkSapiro

MarkSapiro wrote:
I see the problem even if I supply a single DNS address manually which said DNS I can query from another box or with dig in terminal and get a good response.


Not sure why that's the case; you may want to try doing a "sudo dscacheutil -flushcache" just in case a bad response has been cached.

Also, if it's a round-robin issue, wouldn't at least one of several successive retries succeed?


It's not per-request, it's per some (unknown interval/event.)

For example, if your servers are 1.2.3.4 and 2.3.4.5, you'll occasionally find mDNSResponder sending all queries to 2.3.4.5 for an indefinite period of time for whatever reason.
Reply
User profile for user: MarkSapiro
MarkSapiro Author
User level: Level 1
0 points

Oct 28, 2009 8:00 AM in response to Dogcow-Moof

William Kucharski wrote
It's not per-request, it's per some (unknown interval/event.)

For example, if your servers are 1.2.3.4 and 2.3.4.5, you'll occasionally find mDNSResponder sending all queries to 2.3.4.5 for an indefinite period of time for whatever reason.


That could explain what's going on if one of the DNS servers it picks is the router's address supplied by DHCP. My router's DHCP supplies itself as DNS, and it doesn't work very well. However, when I look at the advanced network preferences DNS tab, I only see the addresses I manually added. If I remove them all, I then see the router's address greyed.

So, If SnowLeopard is using the DHCP supplied DNS in addition to the ones I've entered on an unknown/unpredictable basis, that could explain what's happening, but that is exactly the opposite of what you said at http://discussions.apple.com/thread.jspa?messageID=10110379#10110379

But the real question is will this be changed/fixed so that the user can control what DNS server(s) SnowLeopard uses?

Is there a way to raise this issue as a bug report rather than a forum discussion/question? I find the apple web site somewhat opaque. It is hard enough to just find this forum. I have never found bug reports.
Reply
User profile for user: Dogcow-Moof
Dogcow-Moof
User level: Level 8
36,239 points

Oct 28, 2009 1:15 PM in response to MarkSapiro

mDNSResponder will not use a DHCP-supplied DNS server address in SL unless there are none manually set in your Network settings.

Users can control which DNS servers Snow Leopard uses by setting them manually; it's just if more than one is supplied manually (or if you are not setting any manually and more than one is supplied by the DHCP server) you can't really tell which mDNSResponder will use.

There is an existing bug filed on the issue, but unfortunately Apple's bug reporting system does not allow you to see the status of bugs others have filed.
Reply

Name service lookups fail - SnowLeopard

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.
Learn more Sign up