Ordre de recherche DNS de Mac OSX Lion

Question

Après la mise à jour de Mac OSX Lion, j'ai compris que /etc/hosts n'est pas regardé jusqu'à la première place pour la résolution de nom plus. Cela conduit à des effets secondaires comme:

1. Les entrées dans /etc/hosts sont résolus lente et douloureuse
2. Vous ne pouvez pas écraser les domaines existants, par exemple l'adresse 127.0.0.1 www.google.com
3. Si vous obtenez le domaine de recherche des entrées à partir de DHCP, disons .lan, et de drôles de guy configuré localhost.lan à autre chose alors 127.0.0.1 dans le DNS local, vous ne pouvez pas atteindre votre localhost plus.

Est ce comportement est-il destiné? Va-t-il un sens? Et le plus important, comment puis-je revenir à l'ancien comportement.

Merci d'avance

Answer 1

Je pense qu’il est que Lion gère .local TLD différemment parce qu’elle est réservée à certaines fonctionnalités Multicast DNS (utilisées par Bonjour). Le seul moyen que j’ai trouvé pour résoudre ce problème utilise un TLD différent pour les hôtes de développement (c’est à dire : .dev). Il fonctionne très bien pour moi, espère qu’il va être utile à d’autres !

Answer 2

Quant à la redéfinition des domaines dans le fichier hosts, j'ai constaté que dans certaines circonstances, des lions, des requêtes de l'adresse IPv6 pour un domaine si elle détecte qu'un domaine est inaccessible sur le réseau IPv4.

J'ai découvert ça quand j'ai remarqué que certaines annonces que je n'avais jamais vu avant sur Snow Leopard parce que j'avais redirigé ad domaines d' 127.0.0.1. J'ai tiré jusqu'à wireshark et remarqué AAAA (enregistrements DNS IPv6) les requêtes suivantes IPv4 A des requêtes (IPv4). L'annonce serveurs ont, en effet, IPv6 addesses et ont été en mesure de me servir de leur contenu.

La solution pour cela est d'avoir un

::1 mydomain.com

entrée pour chaque

127.0.0.1 mydomain.com

l'entrée dans votre fichier hosts.

Fait intéressant, si vous avez un serveur web local en cours d'exécution sur 127.0.0.1:80 et votre navigateur reçoit une réponse du serveur (erreur ou autre), n' AAAA requête est émise, comme cela semble être convaincu qu'une connexion TCP est au moins possible.

---

Sur une note, si vous faites une utilisation intensive du fichier hosts (pour adblocking, local de développement web, etc), vous voudrez peut-être chercher dans l'exécution de votre propre résolveur DNS. Il y a un grand disque/CPU frapper d'avoir à lire /etc/hosts sur chaque demande, il est donc dans votre intérêt de garder ce fichier très léger.

Un avantage de quelque chose comme dnsmasq localement (outre le gain de performances significatif), c'est que vous pouvez rediriger l'ensemble des domaines de niveau supérieur arrière de votre machine locale. Cela vous permet de disposer de l'ensemble *.dev espace de noms pour le développement (par exemple), sans avoir à saisir individuellement chaque domaine que vous souhaitez résolues localement en /etc/hosts

Answer 3

Le problème était que je liens symboliques du fichier/etc/hosts. Si/etc/hosts est un fichier simple, tout est OK.

Answer 4

Mise à jour: OSX 10.10 Yosemite a remplacé mDNSResponder avec "discoveryd". Je n'ai pas mis à jour donc je ne suis pas sûr de la discoveryd comportement w/r/t des recherches DNS et /etc/hosts.

Le système de résolution DNS sur Lion est l' mDNSResponder processus.

Vous pensez peut-être "mais mDNSResponder est le multicast dns répondeur." Vous avez raison; c'est ce qu'il était à l'origine, et toujours il s'acquitte de cette fonction. Cependant, sur les nouvelles versions de MacOS elle ne standard de l'hôte, les recherches.

En Lion, il ne semble pas automatiquement re-lire /etc/hosts lorsqu'il change, du moins pas toujours. Tuer mDNSResponder (et qui lui permet d'être automatiquement redémarré) semble résoudre le problème.

sudo killall mDNSResponder

devrait faire l'affaire.

ci-dessous ma réponse originale à cette question pour la postérité. Je suppose que ça peut être un problème dans certains cas.

Assurez-vous que votre /etc/hosts le fichier est un style unix fichier texte avec des sauts de ligne sont comme la fin plutôt que de cr.

Montage avec TextWrangler ou un éditeur de texte unix devrait conserver le fichier.

Si votre fichier est déjà foiré, essayez ceci pour fixer

tr '\015' '\012' < /etc/hosts > /tmp/hosts.$$
mv /etc/hosts /etc/hosts.bad
mv /tmp/hosts.$$ /etc/hosts
# fix up permissions while we are at it
chown root:wheel /etc/hosts
chmod 644 /etc/hosts

crédit pour ce correctif:

http://techpatio.com/2011/guides-how-to/fixed-mac-osx-lion-etc-hosts-bugs-dns

Answer 5

j'ai eu ce problème pendant un certain temps, comme im le travail d'une équipe de développeurs, il est devenu nécessaire pour les utiliser .locale plutôt que .dev ou .localhost, j'ai trouvé cet article très utile.

iTand.moi - Lion domaines locaux et etc hôtes..

En résumé;

Mais si vous avez à utiliser .local, la solution la plus élégante que j'ai trouvé est le dscl utilitaire. Son utilisation est très simple. Pour ajouter un hôte appelé mydev.locale et de la pointer vers le localhost, il suffit de faire ceci:

sudo dscl localhost -create /Local/Default/Hosts/mydev.local IPAddress 127.0.0.1

Pour voir tous actuellement définis hôtes et de leurs adresses ip

sudo dscl localhost -list /Local/Default/Hosts IPAddress

Et pour supprimer un hôte:

sudo dscl localhost -delete /Local/Default/Hosts/mydev.local

Dans l'ensemble, assez simple et fonctionne bien. Je préfère encore être en mesure de modifier /etc/hosts à la place, mais c'est une meilleure alternative à avoir à renommer tous nos .les serveurs locaux.