Skip navigation
This discussion is archived

Name service lookups fail - SnowLeopard

1153 Views 5 Replies Latest reply: Oct 28, 2009 1:15 PM by William Kucharski RSS
MarkSapiro Calculating status...
Currently Being Moderated
Oct 27, 2009 3:47 PM
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)
  • William Kucharski Level 6 Level 6 (14,395 points)
    Currently Being Moderated
    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.
    Quad 2.5 GHz G5, 5 GB | 15" 2.6 GHz MBP Penryn, 4 GB | 1 TB Dual-Band TC, Mac OS X (10.6.1)
  • William Kucharski Level 6 Level 6 (14,395 points)
    Currently Being Moderated
    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.
    Quad 2.5 GHz G5, 5 GB | 15" 2.6 GHz MBP Penryn, 4 GB | 1 TB Dual-Band TC, Mac OS X (10.6.1)
  • William Kucharski Level 6 Level 6 (14,395 points)
    Currently Being Moderated
    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.
    Quad 2.5 GHz G5, 5 GB | 15" 2.6 GHz MBP Penryn, 4 GB | 1 TB Dual-Band TC, Mac OS X (10.6.1)

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.