Ordre de recherche DNS Mac OSX Lion

Après la mise à niveau vers Mac OSX Lion, je me suis rendu compte que / etc / hosts n’était plus recherché en premier 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 ignorer 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, laissez dire .lan, et un gars drôle configuré localhost.lan à autre chose que 127.0.0.1 dans le DNS local, vous ne pouvez plus atteindre votre localhost.

Ce comportement est-il destiné? 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 TLD .local différemment car il est réservé à certaines fonctionnalités de DNS Multicast (utilisé par Bonjour). La seule façon de 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 ça va être utile pour les autres!

En ce qui concerne le remplacement de domaines dans le fichier hosts, 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.

Je l’ai découvert lorsque j’ai remarqué des annonces que je n’avais jamais vues auparavant sur Snow Leopard car j’avais redirigé les domaines publicitaires vers 127.0.0.1 . J’ai activé câblé et remarqué les requêtes AAAA (enregistrements DNS IPv6) suite aux requêtes IPv4 A (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.

Il est intéressant de noter que si un serveur Web local tourne sur 127.0.0.1:80 et que votre navigateur reçoit une réponse du serveur Web (erreur ou autre), aucune requête AAAA n’est émise, car il semble être convaincu qu’une connexion TCP a bien eu lieu. le moins possible.


Dans un même ordre d’idées, si vous utilisez beaucoup le fichier hosts (pour le blocage de sites Web, le développement Web local, etc.), vous pouvez envisager de lancer votre propre résolveur DNS local. Le fait de devoir lire /etc/hosts à chaque requête entraîne un impact disque / processeur considérable. Il est donc dans votre intérêt de garder ce fichier très léger.

L’un des avantages de l’exécution de quelque chose comme dnsmasq localement (en plus de l’amélioration significative des performances) est que vous pouvez redirect 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 que vous voulez résoudre localement dans /etc/hosts

Le problème était que je mettais en relation le fichier / etc / hosts. Si / etc / hosts est un fichier simple, 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 découvert avec les recherches DNS et /etc/hosts .

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

Vous pensez peut-être “mais mDNSResponder est le répondeur de diffusion DNS multi-diffusion.” Tu as raison; c’est ce à quoi elle était à l’origine, et elle remplit toujours cette fonction. Cependant, sur les versions plus récentes de MacOS, il effectue également des recherches standard sur les hôtes.

Dans Lion, il ne semble pas relire automatiquement /etc/hosts quand il change, du moins pas toujours. Tuer mDNSResponder (et permettre son redémarrage automatique) semble résoudre le problème.

 sudo killall mDNSResponder 

devrait faire le tour.

ci-dessous est 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 fichier /etc/hosts est un fichier texte de style unix, avec des sauts de ligne comme terminaison plutôt que des crs.

La modification avec TextWrangler ou un éditeur de texte unix devrait préserver le fichier.

Si votre fichier est déjà endommagé, 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 travaillais 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. L’utilisation est très simple. Pour append un hôte appelé mydev.local et le diriger 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 modifier / etc / hosts à la place, mais c’est une meilleure alternative à devoir renommer tous nos serveurs .local.

Avant de passer de Snow Leopard à Lion, j’avais plusieurs entrées spécifiques à l’application dans /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 délai se produisait avant que la requête n’apparaisse dans le fichier journal et qu’une fois cela fait, 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 vraiment, mais ça marche.

Ma situation était similaire, mais les retards, d’exactement 5 secondes, ne se produisaient que pour les URL se terminant par «.local». Lors de l’affichage des sites qui se sont terminés par “.dev”, il n’y a pas eu de retard.

Certains des autres développeurs de mon bureau avaient ce problème, tandis que d’autres ne l’étaient pas. J’espérais un correctif 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 Terminal et j’ai différé 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 Back To My Mac était activé. Une fois que j’ai désactivé Back To My Mac, le résolveur supplémentaire est parti et le délai de 5 secondes a disparu.

Wow, quel cauchemar. J’ai tout lu sur ce sujet et tout ce qui a été suggéré jusqu’à présent était 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 encodé, car je suis le genre de personne qui ne peut l’éditer qu’à partir de la ligne de commande en utilisant emacs. Et, heureusement, je n’ai pas eu à utiliser 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 le démarrage d’Emacs durait environ 10 secondes, mais seulement quand j’étais en wifi. Si j’éteignais le wifi, emacs démarrerait instantanément comme prévu.)

Ma solution: mon portable a un nom, “terminator”. (Oui, son extérieur en aluminium shiny m’a fait penser au personnage d’Arnold Schwarzenegger.) J’avais juste besoin d’append des entrées à / 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 modifié / 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 une 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 …

 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 quelques corrections de bugs. 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 bien pour moi).

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

Après beaucoup de douleur, il semble que mDNSResponder convertisse 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 opposé à partir duquel vous êtes habitué à le voir. Cela corrige tout pour moi. Voici un exemple d’entrée / etc / hosts:

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