Ordre de recherche DNS Mac OSX Lion [fermé]

Après la mise à niveau vers Mac OSX Lion, j'ai compris que / etc / hosts n'était plus recherché en premier lieu pour la résolution de noms. Cela conduit à des effets secondaires tels que:

1. Les entrées dans / etc / hosts sont résolues très lentement
2. Vous ne pouvez pas remplacer les domaines existants, par exemple 127.0.0.1 www.google.com
3. Si vous obtenez des entrées de domaine de recherche à partir de DHCP, disons .lan, et un type drôle a configuré localhost.lan sur autre chose que 127.0.0.1 dans le DNS local, vous ne pouvez plus atteindre votre hôte local.

Ce comportement est-il intentionnel? Celà a-t-il un sens? Et le plus important, comment puis-je revenir à l'ancien comportement.

Je pense qu'il importe que Lion gère le .local TLD différemment car il est réservé à certaines fonctionnalités DNS de multidiffusion (utilisées par Bonjour). Le seul moyen que j'ai trouvé pour résoudre ce problème est d'utiliser un TLD différent pour les hôtes de développement (par exemple: .dev). Cela fonctionne bien pour moi, j'espère que cela sera utile aux autres!

En ce qui concerne le remplacement des domaines dans le fichier d'hôtes, j'ai constaté que dans certaines circonstances, Lion interroge l'adresse IPv6 d'un domaine s'il détecte qu'un domaine est inaccessible sur le réseau IPv4.

J'ai découvert cela lorsque j'ai remarqué des publicités que je n'avais jamais vues auparavant sur Snow Leopard parce que j'avais redirigé les domaines publicitaires vers 127.0.0.1. J'ai déclenché WireShark et remarqué des requêtes ( AAAAenregistrements DNS IPv6) suite aux Arequêtes IPv4 (IPv4). Les serveurs publicitaires ont en effet des addesses IPv6 et ont pu me servir leur contenu.

La solution à cela est d'avoir un

::1 mydomain.com

entrée pour chaque

127.0.0.1 mydomain.com

entrée dans votre fichier hosts.

Fait intéressant, si vous avez un serveur Web local en cours d'exécution 127.0.0.1:80et que votre navigateur reçoit une réponse du serveur Web (erreur ou autre), aucune AAAArequête n'est émise, car il semble être satisfait qu'une connexion TCP était au moins possible.

Sur une note connexe, si vous faites un usage intensif du fichier hosts (pour le blocage des publicités, le développement Web local, etc.), vous voudrez peut-être envisager d'exécuter votre propre résolveur DNS local. Il y a un coup considérable disque / CPU d'avoir à lire /etc/hostsà chaque demande, il est donc dans votre meilleur intérêt de garder ce fichier très léger.

Un avantage d'exécuter quelque chose comme dnsmasqlocalement (en plus de l'augmentation significative des performances) est que vous pouvez rediriger des domaines de premier niveau entiers vers votre ordinateur local. Cela vous permet d'avoir tout l'espace de noms * .dev pour le développement (par exemple), sans avoir à entrer individuellement chaque domaine dans lequel vous voulez être résolu localement/etc/hosts

Le problème était que j'avais lié symboliquement le fichier / etc / hosts. Si / etc / hosts est un simple fichier, tout va bien.

Mise à jour (2): OSX 10.10.5 apporte le retour de mDNSResponder .

Mise à jour: OSX 10.10 Yosemite a remplacé mDNSResponder par "discoveryd". Je n'ai pas mis à niveau, donc je ne suis pas sûr du comportement de découverte avec les recherches DNS r / t et/etc/hosts .

Le résolveur DNS système sur Lion est le mDNSResponder processus.

Vous pensez peut-être "mais mDNSResponder est le répondeur DNS multicast". Vous avez raison; c'est à cela qu'il était à l'origine, et il remplit toujours cette fonction. Cependant, sur les nouvelles versions de MacOS, il effectue également des recherches d'hôte standard.

Dans Lion, il ne semble pas être relu automatiquement /etc/hostslorsqu'il change, du moins pas toujours. Tuer mDNSResponder(et lui permettre d'être automatiquement redémarré) semble résoudre le problème.

sudo killall mDNSResponder

devrait faire l'affaire.

Voici ma réponse originale pour la postérité. Je suppose que cela pourrait encore être un problème dans certains cas.

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

L'édition avec TextWrangler ou un éditeur de texte unix doit préserver le fichier.

Si votre fichier est déjà en panne, essayez ceci pour corriger

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

ive a eu ce problème pendant un certain temps, alors que je travaille avec une équipe de développeurs, il est devenu nécessaire d'utiliser .local plutôt que .dev ou .localhost, j'ai trouvé cet article très utile.

iTand.me - Domaines locaux Lion et hôtes etc.

En résumé;

Mais si vous devez utiliser .local, la solution la plus élégante que j'ai trouvée est l'utilitaire dscl. Son utilisation est très simple. Pour ajouter un hôte appelé mydev.local et le pointer vers l'hôte local, procédez comme suit:

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

Pour voir tous les hôtes actuellement définis et 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érerais toujours pouvoir éditer / etc / hosts à la place, mais c'est une meilleure alternative que de devoir renommer tous nos serveurs .local.

Avant de passer de Snow Leopard à Lion, j'avais plusieurs entrées spécifiques à l'application /etc/hosts, comme ceci:

127.0.0.1 foo.bar.local

Après la mise à jour, le chargement de mes applications locales était TRÈS lent. J'ai remarqué que le retard s'est produit avant que la demande n'apparaisse dans le fichier journal et qu'une fois que c'est le cas, l'application elle-même était aussi rapide que d'habitude.

Maintenant, j'ai deux lignes par application, comme ceci:

127.0.0.1 foo.bar.local
::1       foo.bar.local

... et tout est à nouveau rapide.

Apparemment, cela ajoute des adresses IPv6? Je ne comprends pas tout à fait, vraiment, mais ça marche.

Ma situation était similaire, mais les retards, d'exactement 5 secondes, ne se sont produits que pour les URL se terminant par «.local». Lors de l'affichage des sites qui se terminaient par «.dev», il n'y avait pas de retard.

Certains des autres développeurs de mon bureau ont eu ce problème, d'autres non. J'espérais une solution simple et je ne voulais pas renommer le site en «.local» en raison d'autres dépendances.

J'ai exécuté la commande suivante dans le terminal et j'ai différencié ma sortie avec quelques autres utilisateurs du bureau.

scutil --dns

Cette section était la seule différence:

resolver #2
  domain   : 00000000.members.btmm.icloud.com
  options  : pdns
  timeout  : 5
  order    : 150000

Mon Mac était lié à mon compte iCloud et j'ai activé Back To My Mac. Une fois que j'ai désactivé Back To My Mac, le résolveur supplémentaire a disparu et le délai de 5 secondes a disparu.

Wow, quel cauchemar. J'ai absolument tout lu sur ce sujet et tout ce qui a été suggéré jusqu'à présent était très proche de ce que je vivais, mais aucune des solutions n'a fonctionné pour moi.

Et j'ai compris pourquoi.

Contrairement à d'autres, je n'utilisais pas / etc / hosts pour configurer des domaines locaux. Mon fichier / etc / hosts était stock, ne contenant que les entrées nécessaires pour l'interface de bouclage et l'hôte de diffusion. De plus, c'était un fichier unix correctement codé, car je suis le genre de personne qui ne modifierait cela qu'à partir de la ligne de commande en utilisant emacs. Et, Dieu merci, je n'ai pas eu à recourir à mon propre serveur DNS comme DNSmasq pour contourner le problème.

(Pour être clair, le symptôme qui m'a amené ici à ce problème était que emacs prenait environ 10 secondes pour démarrer, mais seulement lorsque j'étais en wifi. Si je désactivais le wifi, emacs démarrerait instantanément comme prévu.)

Ma solution: mon ordinateur portable a un nom, "terminator". (Oui, son extérieur en aluminium brillant m'a fait penser au personnage d'Arnold Schwarzenegger.) J'avais juste besoin d'ajouter des entrées dans / etc / hosts pour le nom de la machine elle-même:

127.0.0.1   terminator
::1         terminator

J'ai trouvé le nom de mon hôte en exécutant une simple commande dans le terminal:

hostname

... qui est revenu avec la sortie: "terminator". Après avoir changé / etc / hosts pour contenir ces deux entrées, emacs peut maintenant résoudre rapidement le nom de mon ordinateur portable.

J'espère que ça aidera quelqu'un.

J'ai eu des problèmes de vitesse en utilisant OSX Lion comme boîte de développement Web ... En utilisant une combinaison de suggestions, j'ai eu recours à la désactivation du réseau ipv6 et au routage d'ipv6 vers localhost6 ... les choses se sont accélérées un peu ...

sudo networksetup -setv6off Ethernet

/ etc / hosts ...

127.0.0.1    localhost
127.0.0.1    dev.aliasdomain.com
... 
::1          localhost6 

Je pense qu'il y a eu des corrections de bogues. J'ai vu beaucoup de problèmes mentionnés, et aucun de ceux-ci ne semble s'appliquer actuellement (par exemple, mettre plusieurs alias sur une seule ligne fonctionne maintenant très bien pour moi).

En tout cas, il semble qu'avec Lion, Apple ait apporté des modifications drastiques à mDNSResponder qui gère toutes les recherches DNS et (avec Lion au moins) gère également le cache de / etc / hosts. Pour moi, les recherches en avant fonctionnent également maintenant. Mais les recherches inversées (par exemple la recherche de 1.2.3.4 au lieu de google.com) ne fonctionnent pas.

Après beaucoup de peine, il semble que mDNSResponder convertit cette recherche en 4.3.2.1.in-addr.arpa et effectue une recherche de nom. C'est peut-être ainsi que DNS préfère fonctionner, mais cela ne fonctionne pas du tout avec / etc / hosts.

À moins bien sûr que vous ajoutiez un alias de 4.3.2.1.in-addr.arpa pour chaque hôte, où 4.3.2.1 est l'adresse IP dans l'ordre inverse à partir de laquelle vous avez l'habitude de la voir. Cela résout tout pour moi. Voici un exemple d'entrée / etc / hosts:

1.2.3.4 foo foo.example.com alias.example.com 4.3.2.1.in-addr.arpa