La recherche de nom DNS (était SSH) ne fonctionne pas après la mise à niveau de Snow Leopard

je pense que cela a commencé avec la mise à jour de Snow Leopard. Nettoyé le répertoire .ssh, toujours avec le problème.

~: uname -a
Darwin california-example-com.local 10.0.0 Darwin Kernel Version 10.0.0: ven. 31 juil. 22:47:34 PDT 2009; racine: xnu-1456.1.25 ~ 1 / RELEASE_I386 i386

~: ssh -V
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 mars 2009

~: ls -l ~ / .ssh

~: nslookup nevada
Serveur: 10.94.62.3
Adresse: 10.94.62.3 # 53

Nom: nevada.example.com
Adresse: 10.94.62.3

~: ssh nevada
ssh: impossible de résoudre le nom d'hôte nevada: nom de noeud ni nom de serveur fournis, ou inconnu

J'ai rencontré exactement le même problème et trouvé un fil de discussion sur un Mac mini ayant des problèmes DNS sur les discussions d'Apple extrêmement utile.

Le nœud du problème: mDNSResponder semble parfois changer l'ordre des serveurs DNS qu'il interroge et donc s'il interroge d'abord les serveurs DNS de votre FAI, il n'obtiendra pas un enregistrement approprié (ou si vous utilisez un DNS partagé, vous obtiendrez votre adresse IP publique).

La meilleure solution consiste à vous assurer (comme vous l'avez fait) que seuls les serveurs DNS requis sont répertoriés dans vos paramètres DNS. Cela peut nécessiter la suppression des serveurs DNS du FAI de votre DHCP (comme je devais le faire également - toutes les demandes sont transmises via le serveur DNS local de toute façon).

La raison pour laquelle les utilitaires aiment diget nslookupréussiront normalement est qu'ils utilisent BIND et /etc/resolv.confdirectement contrairement au reste du système d'exploitation.

Pour référence dans Snow Leopard, le cache DNS est désormais stocké par mDNSResponder et pour le supprimer, vous devez redémarrer le processus à l'aide de sudo killall -HUP mDNSResponder. Vous pouvez obtenir plus d'informations (journalisation, vidage de l'état interne, etc.) en utilisant différents indicateurs pour la killallcommande.

"sudo killall -USR1 mDNSResponder" to enable operation logging.
"sudo killall -USR2 mDNSResponder" to enable packet logging.
"sudo killall -HUP mDNSResponder" to clear the DNS cache.
"sudo killall -INFO mDNSResponder" to dump mDNSRepsonder's internal state.

Source: Snoop Dogg sur ce même fil.

nous avons eu des problèmes comme celui-ci:

host example.com     <<< WORKED
ping example.com     <<< FAILED

Résolu avec quelque chose comme ça:

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

Les applications sur Mac OS X n'utilisent pas le même mécanisme pour DNS que "host / dig / nslookup".

L'utilisation de "host / dig / nslookup" était utile pour déterminer qu'il ne s'agissait pas d'un problème de réseau. C'était un problème avec le système local résolu avec les commandes ci-dessus.

J'ai rencontré le même problème… Et tandis que le redémarrage de mDNSResponder semble "fonctionner", le redémarrer deux ou trois fois par heure est nul.

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

• Build dnsmasq (téléchargez le tgz et makeou brew install dnsmasq)
• Mettez ceci dans un dnsmasq.conffichier:

fichier resolv = resolv.conf
utilisateur = personne
groupe = personne
interface = lo0
taille du cache = 1024

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

serveur de noms 8.8.8.8
serveur de noms 4.2.2.1
serveur de noms 4.2.2.2

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

...
dnsmasq: lecture de resolv.conf
dnsmasq: utilisation du serveur de noms 4.2.2.1 # 53
dnsmasq: utilisation du serveur de noms 4.2.2.2 # 53
dnsmasq: utilisation du serveur de noms 8.8.8.8 # 53
dnsmasq: lire / etc / hosts - 6 adresses

• 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ées -> 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, donc cela commencera en arrière-plan et vous n'avez pas besoin de garder une fenêtre de terminal ouverte.

J'ai remarqué que j'avais 10.94.62.3 dans la liste des serveurs DNS (volet des préférences réseau) suivi de 2 de mon FAI. J'ai supprimé les 2 autres, forçant toutes les recherches de noms jusqu'à 10.94.62.3 pour cet emplacement et maintenant je peux résoudre les noms sur mon réseau ainsi qu'à l'extérieur.

Je ne sais pas pourquoi cela a fonctionné.

Je suppose que nous avons un problème similaire, comme je l'ai décrit ici: /apple/50457/nslookup-works-ping-and-ssh-dont-os-x-lion-10-7-3

Je crois que le problème réside dans la configuration des domaines de recherche: ping / ssh essayant d'utiliser gethostbyname2()ce qui échoue parce que named ne fonctionne plus (dans Lion au moins) et /etc/resolv.confavec les domaines de recherche configurés est donc ignoré. /etc/hostsest le dernier recours gethostbyname2()et donc ssh fonctionne à nouveau avec des entrées correctes dans /etc/hosts. Doit être corrigé par Apple à mon humble avis.

Avez-vous essayé nevada-example-com.local?

dscacheutil -flushcache

Cette commande actualise votre cache DNS.

10.94.62.3 est-il un serveur DNS de confiance? Si oui, pourquoi n'y en a-t-il qu'un? Vous devez avoir au moins 2 serveurs DNS à consulter à des fins de basculement. Si celui-ci tombe, vous êtes un canard assis.

Les recherches d'ordre DNS semblent fonctionner différemment dans Snow Leopard. Si vous ne pouvez pas rechercher un domaine, vérifiez si vous avez des serveurs DNS non valides répertoriés dans vos préférences réseau. Si vous utilisez une configuration DHCP standard, aucun serveur DNS ne doit être répertorié. Avant ma mise à niveau, j'avais un ancien serveur DNS répertorié, et cela n'affectait rien. Une fois que j'ai mis à niveau, j'ai totalement perdu DNS.

Ouvrez Préférences réseau> Choisissez Aéroport> Avancé. Sélectionnez l'onglet DNS et supprimez tous les serveurs DNS non valides.

Avez-vous regardé la console? (Applications -> Utilitaires -> Console) Vous pouvez constater que mDNSResponder apparaît sous: Informations de diagnostic et d'utilisation -> Rapports de diagnostic du système

S'il se bloque à cause d'un autre programme qui charge des modules (comme Little Snitch ou Hands Off), vous pouvez le voir là-bas.

J'ai eu le même problème avec nslookup en résolvant ma boîte Windows, mais ping me donnant un "hôte inconnu". J'ai essayé ce que Navdeep a suggéré et suis allé effacer les serveurs de noms dans l'onglet Préférences réseau-> Avancé-> DNS. Cela ne me laisserait pas les soustraire, ils étaient grisés. J'ai finalement touché le + et ils ont disparu. J'ai annulé l'ajout d'un nouveau et appliqué des modifications, une fois qu'aucun serveur DNS n'était affiché. Ping a commencé à travailler après cela. Ce qui est étrange, c'est que mon routeur / serveur DHCP local était le premier de la liste et qu'il est responsable de la résolution de la boîte Windows. Ce doit être quelque chose de bizarre avec la commande. L'autre serveur de noms répertorié est un NS de travail et ne pourrait pas résoudre l'hôte Windows. MERCI Navdeep!