DNS non résolu sous Mac OS X


102

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

Ça se passe aussi pour moi sur le lion.
dkagedal


Cela ressemble à un problème historique qui a pourri la vie des utilisateurs et des administrateurs réseau de Léopard à Yosemite. Si quelqu'un voit toujours ce problème, veuillez indiquer clairement si vous avez plus d'une interface active et obtenez en outre sa conf. depuis un serveur DHCP (de différents côtés). Pourquoi? Je n'ai jamais vu un tel problème sur aucun autre Unix et sur aucun de mes Mac (j'en ai beaucoup), mais aucun d'entre eux n'a plus d'une interface parlant vers une source d'informations DNS.
dan

Essayez de changer votre configuration DNS (ordre de changement ou de supprimer des entrées), qui résolvent le même problème pour moi
mems

Réponses:


91

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.


5
Mais ce n'est pas vraiment une réponse satisfaisante. J'ai besoin de savoir comment empêcher cela de se produire.
Jeudi

1
@dkagedal C'est en fait la réponse que nous allons obtenir - cela se produit parce que votre mac met en cache les entrées DNS pour éviter de toucher votre serveur DNS (probablement votre routeur) à chaque recherche DNS - ce qui se produit souvent. Ce cache est nécessaire, et bon, mais ce serait bien s'il y avait un meilleur comportement lorsqu'une entrée n'est pas trouvée (je considère cela comme un bogue). Dans tous les cas, il y a un délai d'attente dans la mémoire cache; Quand j'ai attendu environ 10 minutes sur ma machine, cette situation s'est résolue d'elle-même. Pour la majorité des utilisateurs, le comportement existant est correct, de sorte que Apple ne sera probablement pas modifié de si tôt.
Matt

2
Bien sûr, ce n’est pas aussi bon que cela. Aucun autre OS n'a ce problème. Il n’ya rien de mal avec le DNS, l’enregistrement pour www.google.com n’a pas disparu, c’est juste le cache MacOS qui l’a perdue pour ne pas le récupérer. Et c'est un bug qui doit être corrigé.
dkagedal

1
Vous avez ce problème sur 10.9 et la solution a parfaitement fonctionné. Dans mon cas, le DNS était résolu pour les noms complets mais pas pour les noms courts.
sorin

1
@ Matteo Peut-être que le fichier n'a pas à exister, ou peut-être que la réponse doit être mise à jour pour Yosemite. Avez-vous ce problème? Est-ce que l'exécution de ces commandes le corrige?
CajunLuke

10

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  

3
Vous n'expliquez pas pourquoi ces commandes aideraient à résoudre ce problème. Est-ce qu'ils même? Ou ce que cela signifiait comme un commentaire à l'une des autres réponses ou quelque chose?
Jeudi

Un des avantages possibles de scutil est qu’il peut fonctionner que l’ordinateur ait détecté ou mDNSResponder. Cela date d'avant leur introduction.
DA Vincent

1
ces commandes ne résolvent pas le problème
Radu Simionescu

8

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.


Je voudrais juste souligner qu'après 16 heures consécutives à parcourir Internet, c'est la seule solution que j'ai trouvée qui permette à la fois de résoudre les noms de société internes ET permet au réseau fractionné de fonctionner correctement. Merci beaucoup d'avoir fait ce commentaire.
Ron Thompson

Je tiens également à souligner que sous OS X El Capitan, afin de pouvoir configurer ce script, j’enveloppais ma openconnectcommande dans un script python, avec des commandes telles que networksetup -setdnsservers 127.0.0.1et networksetup -setsearchdomains "$COMPANY_NAME".com. Ajoutez votre dnsmasqcommande et tout est prêt! J'ai enfin une solution VPN stable grâce à ce commentaire.
Ron Thompson

Pour les futurs lecteurs, j'ai trouvé plus facile de simplement ssh dans ma boîte au travail, de déterminer quelle adresse IP il avait pour les serveurs de noms, puis de coder ces adresses IP dans mon resolv.conf inférieur à 8.8.8.8 (serveur DNS googles). Cela permet à tous les noms de société de se résoudre correctement sans passer par les serveurs de la société, ce que je trouve utile pour la confidentialité et la rapidité. En ce qui concerne le codage en dur, ces adresses IP ne changeront pas de sitôt, et si elles le font, je ne serai pas le seul concerné et il devrait être facile de modifier deux lignes.
Ron Thompson

Il est indiqué que l'adresse 127.0.0.1 est déjà utilisée lorsque j'essaie de démarrer Dnsmasq. Que dois-je faire? High Sierra
IceFire

@ IceFire Je sais que c'est vieux, mais cela signifie qu'il existe déjà un service lié à ce port (53). Techniquement, cela signifie que l'erreur est EADDRINUSE, mais je ne vais pas y aller :) En ce qui concerne cette réponse, je la trouve intriguante. J'ai un problème similaire mais je pense (espère) que l'autre réponse résoudra le problème, mais que je n'ai pas besoin de l'activer au moins pour mon réseau domestique, car j'ai mes propres serveurs DNS faisant autorité (et l'un d'entre eux se trouve être local et ce que j'utilise). En tant qu'utilisateur Unix de longue date, le fait que je puisse utiliser /etc/resolv.conf soit attrayant, mais je vais d'abord essayer l'autre.
Pryftan

7

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.


Voir mon édition à la question.
CajunLuke

@CajunLuke hmmmm intéressant… Cela me dérange d'ajouter la sortie de: cat /etc/resolv.conf à votre question?
Martin Marconcini

Édité. (Rembourrage pour rendre le commentaire
ajustable

@CajunLuke, je suis perplexe. Revenons aux racines… cela ne se produit que sur cette machine, et seulement sous OSX, les VM sont ok. Je commence à soupçonner que Parallels ou VMware peut causer des problèmes. Quel type de réseau ces machines virtuelles utilisent-elles? Ponté? Partagé?
Martin Marconcini

1
Ou si vous voulez vraiment faire court, vous pouvez toujours le faire ... dig + short a apple.com ...
Pryftan

6

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.


1
Mon entreprise est aux prises avec ce problème depuis des mois et des mois, amenant chaque fois les Mac à la "barre Genius" dont la seule solution consistait à effacer les disques durs et à tout recommencer. J'ai vu votre message et supprimé com.apple.mDNSResponder.plist, redémarré et le problème a été résolu. J'aimerais pouvoir vous inviter un milliard de fois.
Thomas Thorogood

1
Ne note supprimer com.apple.mDNSResponder.plist! Je l'ai fait comme l'a suggéré @TomThorogood. J'ai du mal à revenir. Même si j'ai remis le fichier et que je l'ai redémarré, je n'ai pas pu obtenir de réponse d'Internet. Le sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistque aidé.
Pavel Binar

5

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!


4

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.


1
C'était aussi la solution pour moi sur Yosemite. Quelques détails: hôte, dig et Chrome fonctionnaient bien, mais ping, telnet, ssh, firefox et safari ne pouvaient pas résoudre les noms d’hôte. Cette solution a résolu mon problème.
Ryan Hoegg le

Ennuyant cela arrive tout le temps pour moi. Je dois redémarrer le service.
Callum Rogers

2

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


2

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


1
Peut-être devrions-nous mentionner support.apple.com/en-au/HT203244 .
DA Vincent

@DAVincent Quelques années de retard, mais ce lien est décevant. C'est clairement un bug d'Apple mais ils l'attribuent à une erreur de l'utilisateur.
Weberc2

2

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.


2

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.


Merci beaucoup, c'était mon problème. Cela fait des heures que je débogue et quand j'ai regardé dans / etc / resolver, j’ai bien sûr trouvé un fichier appelé "test", avec les adresses IP
erronées

Exactement mon problème. Je ne m'en suis rendu compte qu'une fois que je courais scutil --dnset j'ai remarqué que le résolveur n ° 8 avait ajouté des serveurs de noms personnalisés pour mon domaine problématique. J'ai d'abord essayé de les supprimer via l' scutilinterface en ligne de commande, mais sans succès. Et puis je suis tombé sur /etc/resolver... hallelujah! Cette réponse était très utile pour expliquer l'idée de DNS sur macOS.
llude

2

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é.


2

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.


1

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.


1
Bien que la question nécessite peut-être quelques modifications, elle indique toujours (au moment de la rédaction de ce commentaire) que les travailleurs ont déjà essayé d’activer et de désactiver le Wi-Fi. Peut-être pourrions-nous retirer cette réponse?
DA Vincent

Je n'ai pas assez de réputation pour ajouter un commentaire à un article sur l'activation et la désactivation du wifi, mais cela a fonctionné pour moi. Rétracter la réponse serait idiot.

+1 pour la suggestion d'essayer à nouveau. Les réponses multiples aident beaucoup de personnes et chaque routeur a des comportements différents en matière de délais d'attente.
bmike

1

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>

0

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.


0

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!


0

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/


0

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.


0

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

0

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


-1

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.