DNS non résolu sous Mac OS X

Certains de mes collègues rencontrent des problèmes sur leur Mac. La résolution DNS ne fonctionne pas sous Mac OS X. Ils exécutent Snow Leopard 10.6.8. Ils peuvent utiliser DNS sur une machine virtuelle Windows 7 (VMware Fusion 3.1.3) fonctionnant sous OS X. Les ordinateurs sont des modèles MacBook Pros de 15 pouces, modèle début 2011.

Les choses qu'ils ont essayées qui n'ont pas fonctionné:

• allumer / éteindre l'aéroport
• redémarrage
• utilisant une connexion filaire à la place du wifi
• supprimer les identifiants de connexion et les rajouter
• désactiver le pare-feu Mac
• en utilisant une adresse IP statique fixe
• configuration manuelle des serveurs DNS
• redémarrage de mDNSResponder
• les corrections de cette autre question

Réponse EDIT Réponse de Martín:

• Pouvez-vous envoyer une requête ping au DNS que vous souhaitez utiliser?

$ ping apple.com
ping: cannot resolve apple.com: Unknown host

• Quelle est / quelles sont les adresses IP du ou des DNS que vous souhaitez utiliser?

Ceci est un serveur DNS d'entreprise fourni avec DHCP, il fonctionne bien pour d'autres personnes. J'ai également essayé les versions 8.8.4.4 et 205.171.3.65 de Google (que j'ai trouvées dans le test de performances de DNS Benchmark de GRC comme étant les plus rapides).

• Avez-vous essayé d'utiliser 8.8.8.8 (Google) ou l'un des OpenDNS 208.67.222.222 ou 208.67.220.220?

Cela ne fonctionne pas, voir la sortie de Google Chrome:

Le serveur de www.apple.com est introuvable, car la recherche DNS a échoué. DNS est le service réseau qui traduit le nom d'un site Web en son adresse Internet. Cette erreur est le plus souvent provoquée par l'absence de connexion à Internet ou par un réseau mal configuré. Cela peut également être dû à un serveur DNS qui ne répond pas ou à un pare-feu empêchant Google Chrome d'accéder au réseau.

• Pouvez-vous envoyer une requête ping à ces hôtes?

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from
8.8.8.8: icmp_seq=0 ttl=58 time=3.925 ms

• créer un utilisateur vide

Un compte d'utilisateur invité a été créé, le problème DNS était toujours présent lors de l'utilisation du compte d'invité.

• nslookup et creuser les deux fonctionnent bien

$ nslookup www.apple.com 8.8.8.8
Server:  8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
www.apple.com canonical name = www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net canonical name = e3191.c.akamaiedge.net.
Name: e3191.c.akamaiedge.net
Address: 184.24.141.15

$ dig @8.8.8.8 www.apple.com
; <<>> DiG 9.6.0-APPLE-P2 <<>> @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11298
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;www.apple.com.   IN A
;; ANSWER SECTION:
www.apple.com.  1041 IN CNAME www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 38 IN CNAME www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 8794 IN CNAME e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 17 IN A 184.24.141.15
;; Query time: 4 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Oct 4 09:25:28 2011
;; MSG SIZE  rcvd: 158

• vider également le cache DNS a été fait mais cela n'a pas aidé

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

EDIT 2 :

$ cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
domain {redacted}.com
nameserver 8.8.8.8
nameserver 208.67.222.222

Il s’est avéré que la solution consistait à faire rebondir mDNSResponder:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Cela a été obtenu par un collègue différent de cette question d'erreur de serveur .

OS X 10.10.0 - 10.10.3, Yosemite

Apparemment , mDNSResponder n'existe pas dans Yosemite (OS X 10.10). Vous pouvez plutôt redémarrer descoveryd pour résoudre ces problèmes.

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist

OS X 10.10.4+, Yosemite

Dans OSX 10.10.4, le répondeur mDNS a été réintroduit . Alors utilisez le premier fonctionnera à nouveau.

En fait, je pense que vous voudrez peut-être utiliser

scutil --dns

scutil -r hostname

Ces commandes utilisent le magasin dynamique de configd, par opposition aux fichiers plats de / etc, qui ne sont souvent lus qu'en mode mono-utilisateur et pour les systèmes sans réseau.

man scutil   # or

scutil --help  

J'ai rencontré le même problème… Et lors du redémarrage de mDNSResponder, il semble que cela «fonctionne», en le redémarrant plusieurs fois par heure, ça craint.

Donc, pour le moment, j'ai "résolu" le problème en exécutant dnsmasq localement. Pour faire ça:

• Construire dnsmasq (télécharger le tgz et makeou brew install dnsmasq)

• Mettez ceci dans un dnsmasq.conffichier:

  resolv-file=resolv.conf
  user=nobody
  group=nobody
  interface=lo0
  cache-size=1024
  

• Placez ceci dans un resolv.conffichier qui se trouve dans le même répertoire que le dnsmasq.conffichier (nb: not /etc/resolv.conf ):

  nameserver 8.8.8.8
  nameserver 4.2.2.1
  nameserver 4.2.2.2
  

• Courez dnsmasqavec sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf. La sortie devrait ressembler à quelque chose comme:

  ...
  dnsmasq: reading resolv.conf
  dnsmasq: using nameserver 4.2.2.1#53
  dnsmasq: using nameserver 4.2.2.2#53
  dnsmasq: using nameserver 8.8.8.8#53
  dnsmasq: read /etc/hosts - 6 addresses
  

• Ouvrez les Préférences réseau et assurez-vous qu'il 127.0.0.1s'agit du seul serveur DNS (Préférences réseau -> Avancé -> DNS -> Ajouter 127.0.0.1).

Les choses devraient recommencer à bien fonctionner.

Une fois que les choses fonctionnent, vous pouvez exécuter dnsmasqsans les options --no-daemonet --log-queries, ainsi, cela démarrera en arrière-plan et vous n'avez pas besoin de garder une fenêtre de terminal ouverte.

La résolution de noms sous OSX (et UNIX en général) provient des adresses IP des DNS du fichier situé dans /etc/resolv.conf (qu'OS X génère automatiquement, pour autant que je puisse m'en souvenir).

Puisque vous avez essayé pratiquement tout ce qui me passe par la tête, j'aimerais vous demander:

• Pouvez-vous envoyer une requête ping au DNS que vous souhaitez utiliser?
• Quelle est / quelles sont les adresses IP du ou des DNS que vous souhaitez utiliser?
• Avez-vous essayé d'utiliser 8.8.8.8 (Google) ou l'un des OpenDNS 208.67.222.222 ou 208.67.220.220?
• Pouvez-vous cingler ces hôtes?

Enfin, un test généralement intéressant consiste à créer un utilisateur vide et à vérifier si ce nouvel utilisateur présente le même problème. Si ce n'est pas le cas, vous pouvez alors commencer à chercher ce que votre utilisateur actuel pourrait être à l'origine du problème. si cela échoue aussi, alors vous savez que c'est quelque chose de plus lié au "système".

Jetez également un coup d'œil autour de la console pour voir si vous pouvez repérer quelque chose qui pourrait être lié (et que vous souhaitez coller ici).

Enfin, votre Mac est livré avec deux commandes DNS importantes, nslookupet dig.

Donc, pour résoudre www.apple.com en utilisant le serveur de Google, vous devez taper:

nslookup "hôte à résoudre" "serveur DNS à utiliser". Par exemple:

$ nslookup www.apple.com 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
www.apple.com   canonical name = www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net    canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net   canonical name = e3191.c.akamaiedge.net.
Name:   e3191.c.akamaiedge.net
Address: 184.24.141.15

NSLookup est une ancienne commande (censée être obsolète il y a quelques années et remplacée par DIG, mais sa syntaxe facile à utiliser était trop bonne pour être éliminée, je suppose.), Sa "substitution" est digune commande beaucoup plus puissante, dont la syntaxe est plus fou.

Pour effectuer la même requête, vous devez taper:

dig @ 8.8.8.8 www.apple.com

Et voici la sortie:

$ dig @8.8.8.8 www.apple.com

; <<>> DiG 9.7.3 <<>> @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17356
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

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

;; ANSWER SECTION:
www.apple.com.      1782    IN  CNAME   www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 42 IN CNAME   www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 21581 IN CNAME   e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 2   IN  A   184.24.141.15

;; Query time: 26 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Oct  3 21:21:49 2011
;; MSG SIZE  rcvd: 158

Comme vous pouvez le constater, creuser est beaucoup plus "prolixe" (ce qui est bien pour déboguer sur ce qui se passe). La puissance de dig provient du fait que vous pouvez spécifier le type de requête que vous souhaitez effectuer (entre autres).

Dans tous les cas, indiquez nous les résultats exacts de ces commandes.

J'avais exactement les mêmes symptômes (et j'ai passé du temps à résoudre des problèmes), mais j'ai réussi à les résoudre quand j'ai réalisé que je me suis trompé /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistet que ce que j'ai fait a été interprété d'une manière ou d'une autre comme malformé. J'ai restauré à partir d'une sauvegarde et la machine a été capable de résoudre à nouveau les noms d'hôte.

Avant d’arriver à la solution, j’ai aussi réalisé que j’étais capable de naviguer sur Internet si j’utilisais un proxy SOCKS5 ssh -Det tentais des recherches DNS dans le tunnel.

J'ai eu un problème très, très similaire, sauf que les symptômes étaient légèrement différents.

Mon utilisateur ne peut résoudre aucun nom (NAS local, Google, etc.), mais un utilisateur invité sur le même iMac (OS X 10.7.4) fonctionne correctement.

Le rinçage et le redémarrage de mDNSResponder comme indiqué ont duré un certain temps. Tandis qu'il continuerait à fonctionner lorsque l'iMac serait mis en mode veille, il échouerait toujours une fois redémarré.

Lorsque le vidage / le redémarrage a cessé de fonctionner, j'ai cherché d'autres raisons / solutions et j'ai constaté que cela était lié à mon pare-feu. Je ne sais pas ce qui l' a causé dans mes paramètres de pare-feu (OS X), mais si je restaurais le paramètre de pare-feu, cela fonctionnerait.

Pour restaurer les paramètres par défaut que j'ai utilisés:

sudo cp /usr/libexec/ApplicationFirewall/com.apple.alf.plist /Library/Preferences/com.apple.alf.plist

De toute évidence, toutes les règles personnalisées auront été supprimées avec cette restauration.

Je voulais partager ma version de ce numéro, car cela me causait des problèmes de temps en temps et cet article est la meilleure collection de solutions possibles sur le net!

Je frappe ce problème sur Yosemite (10.10). Il s'avère qu'un démon clé a discoverydété tué car il consommait trop de ressources processeur.

2014/10/22 3:50:07.000 PM kernel[0]: process discoveryd[49] thread 1251 caught burning CPU! It used more than 50% CPU (Actual recent usage: 68%) over 180 seconds. thread lifetime cpu usage 90.016372 seconds, (74.516637 user, 15.499735 system) ledger info: balance: 90007570271 credit: 90007570271 debit: 0 limit: 90000000000 (50%) period: 180000000000 time since last refill (ns): 131905306167 

Étrangement, le redémarrage ne l’a pas provoqué.

J'ai redémarré manuellement le service avec:

sudo launchctl kickstart -k system/com.apple.networking.discoveryd

et maintenant tout va bien.

J'ai le même problème avec 10.6.8. La première visite dans un Apple Store a entraîné une restauration du système. Mais après cela, DNS a de nouveau éclaté alors que j'étais outre-mer et je n'avais pas de DVD système avec moi. A cette époque, j'ai trouvé ce fil et supprimé /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistpar @freezedpeanuts et @Tom Thorogood.

Le problème a été résolu, mais étonnamment, le DNS a éclaté pour la troisième fois quelques jours plus tard. J'ai recherché une image système de 10.6.3 et:

1. Copié à /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistpartir de l'image système.
2. sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
3. Redémarré

Cela a résolu le problème.

Il effectue des interruptions périodiques pour moi maintenant (environ une fois par mois), et la procédure de restauration se résume aux étapes ci-dessus, mais au lieu de redémarrer, vous pouvez:

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Veuillez noter que si vous rencontrez toujours des problèmes, vous devrez peut-être supprimer tout serveur DNS public jusqu'à la suppression du cache.

J'avais apparemment le même problème que le PO. En utilisant l'outil networksetup, j'ai constaté que pour le nom de réseau donné, un mauvais DNS avait été configuré:

networksetup -getdnsservers <networkname>

répertorié 192.168.0.1 en tant que DNS. Utilisation de scutil --dns J'ai des résultats comparables, indiquant que le résolveur n ° 2 utilisait le serveur de noms [0]: 192.168.0.1.

Utiliser la commande

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

J'ai été en mesure de reconfigurer le DNS pour le réseau donné et de résoudre les noms des machines locales et globales une fois connecté au VPN.

Cela n’aidera probablement personne, mais au cas où j’ai accidentellement créé un fichier dans le dossier il ya quelque temps, lorsqu’un DNS était arrêté pour un domaine particulier:

/ etc / resolver /

et cela empêchait un nom spécifique d'être jamais résolu, deux ans plus tard.

Dans mon cas, tout le reste était bien: mDNSResponder était en cours d' exécution et de travail, host/ a nslookuptravaillé, à la fois /etc/resolv.confet a networksetupsignalé les serveurs DNS corrects, etc. Malgré tout, la résolution DNS en général (par exemple avec ping) inévitablement cessé de travailler à un moment donné quelques heures après démarrage.

Ce problème spécifique est peut-être quelque peu improbable, mais je vais le documenter ici comme réponse.

Je n'ai remarqué que lorsque la machine a commencé à ralentir, mais il y avait beaucoup de processus identiques en cours d'exécution . sensu-client, Plus précisément.

Nous l'avions configuré dans launchd avec ce fichier plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd>
<plist version="1.0">
  <dict>
  <key>KeepAlive</key>
  <true/>
  <key>RunAtLoad</key>
  <true/>
  <key>WorkingDirectory</key>
  <string>/etc/sensu</string>
  <key>UserName</key>
  <string>root</string>
  <key>Label</key><string>org.sensuapp.sensu-client</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/bin/sensu-client</string>
      <string>-d/etc/sensu/conf.d/</string>
      <string>-b</string>
    </array>
  </dict>
</plist>

Le -bdrapeau à sensu-clientfaire basculer à l'arrière-plan, agissant comme un démon. Cependant, tout le monde launchdvoit que le processus initial a pris fin et le KeepAliveredémarre (conformément à l' indicateur). Cela laisse des milliers de processus forkés en arrière-plan, et même alors, launchd ne sera pas plus sage du fait qu'il est en cours d'exécution.

Je pense que ces plusieurs milliers de processus ( sensu-clientle logiciel pour lequel nous avons écrit une configuration launchun) ont peut-être envoyé simultanément des demandes à mDNSResponder, ce qui a effectivement entraîné un déni de service du cache DNS . Tuer ces processus et corriger le plist donné à launchd ont finalement résolu le problème.

La solution de plist consistait simplement à supprimer l' -bindicateur (background / daemonise) de l'invocation sensu-client. Notez que ce n'est pas la faute de Sensu; Ce plist a été écrit par un ancien administrateur système de cette société.

Voici quelques commandes avancées qui peuvent aider à résoudre le problème DNS:

• Exécuter digpour répertorier les serveurs de noms racine.
• Exécuter dig example.compour lancer la recherche DNS pour le example.comdomaine.
• La liste de vos ports matériels par: networksetup -listallhardwareports.
• Vérifiez la sortie du paquet DHCP / BOOTP que le client a accepté du serveur DHCP / BOOTP par: ipconfig getpacket en0.
• Vérifiez votre configuration DNS par: scutil --dns.
• Vérifiez que mDNSResponderprocessus est exécuté par: ps wuax | grep mDNSResponder.
• Vider les entrées de traduction ARP par: arp -ad( man arpdemander de l'aide). ^{la source}

Pour déboguer le mDNSResponderprocessus, la commande suivante peut aider:

(sleep 1 && sudo killall -INFO mDNSResponder &); log stream | grep mDNSResponder

La commande ci-dessus enverra un SIGINFOsignal au processus qui dumpera les détails du débogage dans la sortie du journal qui pourra être lue et analysée.

Activer et désactiver le Wi-Fi a aidé.

^{MacBook Pro avec 10.9.1}

Surtout si vous désactivez le wifi, puis redémarrez. Le délai supplémentaire et l'absence de connexion IP / réseau garantissent que la demande de rejoindre le réseau a de meilleures chances de réussir.

Malheureusement, rien de tout cela ne m'a aidé, et s'est avéré après une heure d'essayer de comprendre et de me frapper la tête contre la table basse… quelque chose, quelque part, quelque part… a supprimé le /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistfichier, et a été la raison pour laquelle j'ai eu ce problème.

Réalisé ceci quand j'ai vu ce message d'erreur: /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist: No such file or directory

Voici une copie d'une version d'El Capitan: https://gist.github.com/tripflex/e7147690d1768dc74b1dd626614573c0

Voici le code de cette essence:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.apple.mDNSResponder.reloaded</string>
    <key>OnDemand</key>
    <false/>
    <key>InitGroups</key>
    <false/>
    <key>UserName</key>
    <string>_mdnsresponder</string>
    <key>GroupName</key>
    <string>_mdnsresponder</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/sbin/mDNSResponder</string>
    </array>
    <key>MachServices</key>
    <dict>
        <key>com.apple.mDNSResponder</key>
        <true/>
            <key>com.apple.mDNSResponder.dnsproxy</key>
            <true/>
    </dict>
    <key>Sockets</key>
    <dict>
        <key>Listeners</key>
        <dict>
            <key>SockFamily</key>
            <string>Unix</string>
            <key>SockPathName</key>
            <string>/var/run/mDNSResponder</string>
            <key>SockPathMode</key>
            <integer>438</integer>
        </dict>
    </dict>
    <key>POSIXSpawnType</key>
    <string>Interactive</string>
    <key>EnablePressuredExit</key>
    <false/>
</dict>
</plist>

En fin de compte, pour résoudre le problème, vous devez configurer un domaine de recherche et l’ajouter au champ de domaine de recherche sous Configuration DNS du système. Fondamentalement, le domaine de recherche fonctionnera de la même manière que .local, mais ce sera plutôt le cas.

Pour que cela fonctionne, vous devez configurer votre domaine de recherche en tant que zone maître dans votre serveur DNS.

J'ai un problème similaire à trouver le serveur hôte. Nous avons 21 iMac fonctionnant à partir du serveur (El Capitan, récemment mis à niveau) et un seul ne se liera pas. Le correctif est généralement assez simple via Utilisateurs et Groupes dans SysPref. Suppression du serveur hôte et nouvelle liaison, recherche du serveur disponible dans l'option de liste déroulante, mais pour une raison inconnue, le serveur est répertorié sous le nom unkown-00-00-12-34-56-78.homecorrespondant à l'adresse MAC du serveur. J'ai couru ceci dans le terminal:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

et

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

est retourné se lier au serveur dans SysPref et l’option de nom de serveur correcte est brièvement apparue puis est revenue à "unkown-00-00-12-34-56-78.home" juste devant mes yeux!

En suivant les commandes de réponse acceptée:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

vous pouvez être averti:

Opération non autorisée tant que la protection de l'intégrité du système est activée

Vous devez l'éteindre. Toute l'instruction ici: https://www.howtogeek.com/230424/how-to-disable-system-integrity-protection-on-a-mac-and-why-you-shouldnt/

Dans mon cas, j'avais déjà installé OpenDNS et il n'avait pas été supprimé proprement. Plusieurs processus liés au DNS, tels que DNSdnscrypt-proxy, étaient en cours d'exécution. Je ne pouvais pas les forcer à quitter Activity Monitor, mais je pouvais les empêcher de démarrer au redémarrage en supprimant le fichier .plist dans Library / LaunchDaemons.

Allez dans Paramètres -> Réseau -> Avancé -> DNS. Ensuite, apportez littéralement toute modification au DNS (réorganisez vos entrées DNS, par exemple). Cliquez ensuite sur "Ok" suivi de "Appliquer" sur l'écran suivant. Ne vous fiez pas de penser que le changement que vous avez apporté était important; c'est la magie du bouton "Appliquer".

~ $  time nslookup www.google.com
;; connection timed out; no servers could be reached


real    0m21.041s
user    0m0.006s
sys     0m0.010s

 ~ $  time nslookup www.google.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   www.google.com
Address: 172.217.5.4


real    0m0.079s
user    0m0.006s
sys     0m0.010s

Ce qui a fonctionné pour moi a été de supprimer toutes les entrées de serveur des serveurs DNS et des domaines de recherche de:

Préférences Système → Réseau → Avancé ... → DNS

Après la mise à niveau de Snow Leopard sur un ancien Mac Book vers Mountain Lion, le système n'a pas pu résoudre le DNS. Flushing, redémarrer, rien n'a aidé. Changer de WiFi sur un autre point d'accès (mon téléphone) m'a aidé.

Mountain Lion ajoute un nouveau champ client aux paramètres réseau DHCP. Remplir ce champ semblait rendre le point d'accès wifi heureux. Le laisser vide signifiait que rien ne passait, même si la connexion wifi semblait réussir.