Le DNS ne se résout pas sur Mac OS X

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 pouvait résoudre aucun nom (NAS local, Google, etc.) mais un utilisateur invité sur le même iMac (OS X 10.7.4) fonctionnait bien.

Le vidage et le redémarrage de mDNSResponder comme indiqué ont fonctionné pendant un certain temps. Alors qu'il continuait à fonctionner lorsque l'iMac était mis en mode veille, il n'y avait pas de problème. toujours échoue une fois redémarré.

Lorsque le rinçage/redémarrage a cessé de fonctionner, j'ai cherché d'autres raisons/solutions et j'ai découvert que le problème était lié à mon pare-feu. Je ne sais pas ce que dans les paramètres de mon pare-feu (OS X) en était la cause, mais si je rétablis les paramètres du pare-feu, cela fonctionne.

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

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

Évidemment, toute règle personnalisée aura été supprimée lors de cette restauration.

Je voulais partager ma version de ce problème, car il me cause des ennuis depuis des mois et cet article est la meilleure collection de solutions possibles sur le net !

J'ai rencontré ce problème sur Yosemite (10.10). Il s'avère qu'un démon de clé, discoveryd a été tué car il consommait trop de CPU.

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 

Bizarrement, le redémarrage n'a pas provoqué de redémarrage.

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

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

et maintenant tout va bien.

Désactiver et réactiver le Wi-Fi a aidé.

MacBook Pro avec 10.9.1

Surtout si vous désactivez le wifi et que vous redémarrez. Le délai supplémentaire et le fait de commencer sans connexion IP/réseau garantissent que la demande de réintégration du réseau a plus de chances d'aboutir.

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

networksetup -getdnsservers <networkname>

a listé 192.168.0.1 comme DNS. En utilisant scutil --dns j'ai obtenu des résultats comparables, listant que le résolveur #2 a utilisé le nameserver [0] : 192.168.0.1.

En utilisant la commande

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

J'ai pu reconfigurer le DNS pour le réseau donné et résoudre les noms des machines locales et globales lorsqu'elles sont connectées au VPN.

Dans mon cas, tout le reste allait bien : mDNSResponder était en cours d'exécution et fonctionnait, host / nslookup a fonctionné, les deux /etc/resolv.conf y networksetup a signalé les bons serveurs DNS, etc. Malgré tout cela, la résolution DNS en général (par exemple avec ping ) a inévitablement cessé de fonctionner à un moment donné, quelques heures après le démarrage.

Ce problème spécifique est peut-être un peu improbable, mais je vais quand même le documenter ici en tant que réponse.

Je n'ai remarqué que lorsque la machine a commencé à ralentir, mais il y avait un grand nombre de processus identiques en cours d'exécution . sensu-client en particulier.

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 site -b pour sensu-client le fait passer en arrière-plan, agissant comme un démon. Cependant, toutes les launchd voit que le processus d'origine s'est terminé, donc (conformément à l'approche de la KeepAlive ), il le redémarre. Cela laisse des milliers de processus bifurqués en arrière-plan, et même dans ce cas, launchd ne sera pas conscient du fait qu'il est en cours d'exécution.

Je crois que ces plusieurs milliers de processus (tous sensu-client (le logiciel pour lequel nous avions écrit une configuration launchd) peut avoir fait simultanément des demandes à mDNSResponder, ce qui a entraîné un problème d'accès aux données. déni de service local du cache DNS . En tuant ces processus et en corrigeant le plist donné à launchd, le problème a été résolu.

Le correctif plist consistait simplement à supprimer le -b (background / daemonise) de l'invocation sensu-client. Notez que ce n'est pas la faute de sensu ; cette plist a été écrite par un ancien administrateur système de cette société.