Les recherches DNS échouent avec par exemple `ping`, mais fonctionnent avec` host`

J'utilise pfSense 2.0rc3, je l'ai configuré comme un redirecteur DNS et j'ai activé "Enregistrer les baux DHCP dans un redirecteur DNS". Ce que je comprends, ce sont tous les paramètres appropriés pour obtenir un serveur DNS pour les recherches locales.

Cela fonctionne comme prévu avec Linux et en particulier, je peux exécuter host abcet ping abc(et d’autres applications) et ils fonctionnent tous comme prévu.

Cependant, sous Mac OS X Lion 10.7, cela ne fonctionne pas comme prévu. En particulier, seules les recherches avec la hostcommande semblent fonctionner, c.-à-d.

$ ping abc
ping: cannot resolve abc: Unknown host

$ host abc
abc.local has address 192.168.1.128

$ ping abc.local
ping: cannot resolve abc.local: Unknown host

$ host abc.local
abc.local has address 192.168.1.128

Pourquoi la recherche de abctravail fonctionne-t-elle avec la hostcommande mais échoue avec ping(et d'autres applications)?

Merci d'avoir lu.

Pourquoi ils ont fait ce changement, je ne sais pas, mais cela m'a rendu fou pendant un moment.

Je ne sais pas pourquoi les choses fonctionnent pour l'hôte, mais pas pour le ping, mais je pense que cela a à voir avec la nature de ces deux utilitaires. Ping est un utilitaire de diagnostic simple (bien que très utile) permettant de déposer des paquets sur le fil qui devrait vous être renvoyé en écho. La fonctionnalité de recherche de nom d’hôte n’est qu’un effet secondaire du travail et est transmise au résolveur récursif du système (je crois - je n’ai pas vérifié en vérifiant les bibliothèques liées ou quoi que ce soit de ce genre). La tâche principale de l'hôte consiste à résoudre les noms DNS. Il implémente donc son propre résolveur récursif.

Le résolveur récursif d’Apple est mDNSResponder. Pour une raison quelconque, la version de mDNSResponder dans Lion a besoin de l’option de ligne de commande "-AlwaysAppendSearchDomains" pour se comporter comme dans Snow Leopard (au moins).

Voici un moyen rapide de résoudre ce problème:

sudo sed -i .orig '/ProgramArguments/,/<\/array>/ {
s/\(<string>-launchd<\/string>\)/\1\
                <string>-AlwaysAppendSearchDomains<\/string>/
}' /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

(Il devrait y avoir deux caractères de tabulation au début de l'avant-dernière ligne, mais je ne savais pas comment faire en sorte que ce petit éditeur insère des tabulations. J'ai donc ajouté 16 espaces. Cela devrait fonctionner, mais les tabs cadrer mieux l’espacement du fichier original.)

Ceci ajoutera l'argument "-AlwaysAppendSearchDomains" au fichier de plist de démarrage mDNSResponder (et sauvegardera une copie de sauvegarde), mais comme il est contrôlé par launchd, le système doit être invité à redémarrer mDNSResponder.

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

Maintenant, si vous vérifiez votre processus en cours d'exécution mDNSResponder, vous devriez le voir fonctionner avec votre nouvel argument:

ps auxww | grep mDNSResponder

(Accessoires à http://www.makingitscale.com/2011/fix-for-broken-search-domain-resolution-in-osx-lion.html et http://kavassalis.com/2011/07/wtf-bug -in-os-x-10-7 / , où j’ai trouvé mes réponses à ce problème.)

Depuis la page de manuel hôte (1):

AVIS Mac OS X

La commande host n'utilise pas la résolution du nom et de l'adresse de l'hôte ni les mécanismes de routage de la requête DNS utilisés par d'autres processus s'exécutant sous Mac OS X. Les résultats des requêtes de nom ou d'adresse imprimées par l'hôte peuvent différer de ceux trouvés par d'autres processus utilisant le Mac. Mécanismes de résolution de noms et d'adresses natifs d'OS X Les résultats des requêtes DNS peuvent également différer de ceux utilisant la bibliothèque de routage DNS Mac OS X.

Malheureusement, il n'existe aucune information sur la manière dont la commande host résout les noms d'hôte. Ce comportement le rend quelque peu inutile pour le débogage, à mon humble avis.

Historique basique ... nslookup était la commande, mais elle avait sa propre implémentation de toutes ses routines de résolveur. Ce qui a commencé à se produire est que les résolveurs de système sur différentes plates-formes fonctionnent différemment de nslookup. Parfois, cela produirait des résultats assez différents.

Les commandes host et dig ont été créées en tant que "réécriture" pour nslookup. Ils se lient statiquement dans les fonctions du résolveur système. Le résolveur système est un ensemble de fonctions de la bibliothèque C standard d'un système UNIX ou de systèmes similaires (sous Mac OS X, ces fonctions font partie de la bibliothèque netdb). Ainsi, les commandes host et dig fonctionnent toujours de la même manière que le résolveur système, quel que soit le système d’exploitation pour lequel elles ont été créées, mais elles n’en dépendent pas. De cette manière, ils constituent d’excellents outils de diagnostic dans les cas où le résolveur système ne fonctionne pas correctement.

REMARQUE: Hébergez et digérez la liste de serveurs de noms depuis /etc/resolv.conf, sauf s’ils disposent d’un serveur de noms spécifique à qui parler. Seule la commande host utilise la liste de recherche du fichier /etc/resolv.conf; dig ne le fait pas, raison pour laquelle il faut toujours donner le nom de domaine complet à dig pour résoudre quelque chose. Les deux commandes sont par ailleurs entièrement autonomes; Par exemple, le fichier /etc/resolv.conf est la seule chose qu'ils ne utilisent pas dans le fichier binaire.

mDNSresponder est Bonjour. Je ne me suis pas plongé dans les détails, mais je soupçonne que ce paramètre de configuration ne résout pas le problème, ou du moins, pas directement. Je viens de rencontrer le même problème sous Mac OS X 10.9.1 et le simple redémarrage de mDNSresponder a résolu le problème pour moi. Je n'ai jamais vu ce problème auparavant sur 10.5 -> 10.8 / 10.9 sur un autre système. De plus, cela n’affectait pas les applications graphiques, c’était uniquement les outils en ligne de commande, tels que ping et ssh, qui étaient en panne.

Si je trouve le temps de fouiller un peu plus dans la bibliothèque, je verrai si je peux trouver une explication plus complète.

J'ai mis en place un script shell pour automatiser le correctif (et un programme de désinstallation si vous en avez besoin ultérieurement), ici:

https://github.com/michthom/AlwaysAppendSearchDomains

Cela devait être distribué à des utilisateurs moins techniques au travail qui pourraient craindre d’éditer manuellement des fichiers système.

.local est réservé à la multidiffusion. Les serveurs mDNS et DNS sur le même réseau utilisant .local peuvent poser problème.

L'hôte ajoute le suffixe DNS local .local. Ping n'est pas. Si vous trouvez cela déconcertant, vous pouvez ajouter .local comme suffixe par défaut dans les préférences système du réseau. Le système ajoutera cela lors de la tentative de résolution des noms d'hôte.

Si vous avez essayé tout ce qui précède et rien travaillé , vous pouvez alors ajouter vos serveurs de noms et chemins de recherche àSystem Preferences>Network>Advance(bottom right of the window)>DNS tab

Ceci met à jour /etc/resolv.conf et ping devrait maintenant fonctionner. Mettre à jour le chemin de recherche en éditant /etc/resolv.conf ne fonctionne pas vraiment, mais cela fonctionne pour une raison quelconque.

MISE À JOUR:

La modification de /etc/resolv.conf ne fonctionne pas car le système d'exploitation réécrit le fichier en fonction du paramètre de la sous-fenêtre Préférences Système.

Je manque de réputation pour commenter le post de Lamont Peterson . Le redémarrage de mDNSresponder a fonctionné pour moi sous Mac OS X 10.7 (Lion). Contrairement à Lamont Peterson, ce problème m'a causé des problèmes avec une application d'interface graphique: Safari ne pouvait pas résoudre les noms d'hôtes publics ou privés. Voici les étapes spécifiques que j'ai faites et que je soupçonne également de Lamont Peterson:

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

Le unloadmDNSresponder s’arrête et le loadredémarre.

Cela a résolu le problème immédiatement; aucun redémarrage requis.

Vous pouvez vérifier qu'il a bien redémarré en utilisant la listcommande:

$ sudo launchctl list | grep '^PID\|mDNSResponder'
PID     Status  Label
708     -       com.apple.mDNSResponder
-       0       com.apple.mDNSResponderHelper

La présence d'un ID de processus (PID) signifie qu'il est en cours d'exécution. 708variera comme il est assigné par le système d'exploitation. Si le statut indique autre chose qu'un trait d'union ou un zéro, quelque chose s'est mal passé.

Je ne sais pas comment mDNSResponderHelperinteragit avec mDNSResponder; Je n'ai jamais eu à redémarrer mDNSResponder.

En une ligne:

sudo kill $(ps ax | grep mDNSResponder | grep -v grep | grep -v Helper | awk '{ print $1 }')

Les notes sur les noms OSX peuvent être non standard, donc pour être complet:

• FQDN sont pingable
• les noms dans les fichiers "hôtes" sont pingables

Les noms Mac NE SONT PAS en général: deux corrections doivent être apportées: a) modifier les espaces en "-" b) ajouter .local

Ainsi, par exemple, mon Mac: le MacBook Pro d’ingconti

sera pingable à: ingcontis-macBook-pro.local

Et les préférences d'ouverture que vous pouvez voir: