Ordre de recherche DNS Mac OSX Lion
Après la mise à niveau vers Mac OSX Lion, j’ai réalisé que la résolution de noms n’était plus recherchée dans/etc/hosts. Cela conduit à des effets secondaires tels que:
- Les entrées dans/etc/hosts sont résolument lentes
- Vous ne pouvez pas remplacer les domaines existants, par exemple. 127.0.0.1 www.google.com
- Si vous obtenez des entrées de domaine de recherche de DHCP, disons .lan, et un type marrant qui a configuré localhost.lan à quelque chose d'autre que 127.0.0.1 dans le DNS local, vous ne pouvez plus atteindre votre hôte local.
Ce comportement est-il voulu? 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 fichier .local de manière différente, car il est réservé à certaines fonctionnalités DNS de multidiffusion (utilisées par Bonjour). La seule solution que j'ai trouvée pour résoudre ce problème consiste à utiliser un autre TLD pour les hôtes de développement (c'est-à-dire: .dev). Cela fonctionne bien pour moi, j'espère que ça va aider les autres!
En ce qui concerne la redéfinition des 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.
J'ai découvert cela en remarquant des publicités que je n'avais encore jamais vues sur Snow Leopard, car j'avais redirigé les domaines de publicité vers 127.0.0.1. J'ai lancé WireShark et remarqué que les requêtes AAAA (enregistrements DNS IPv6) suivaient les requêtes IPv4 A (IPv4). Les serveurs de publicité ont effectivement des adresses 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 s'exécutant sur 127.0.0.1:80 et que votre navigateur reçoive 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 était au moins possible.
Sur une note connexe, si vous utilisez beaucoup le fichier hosts (pour l’adblocking, le développement Web local, etc.), vous pouvez envisager d’exécuter votre propre résolveur DNS local. Le fait de devoir lire /etc/hosts à chaque demande, il est donc dans votre intérêt de garder ce fichier très léger.
L’exécution locale de quelque chose comme dnsmasq (en plus de l’amélioration significative des performances) vous permet de rediriger des domaines entiers de premier niveau vers votre ordinateur local. Cela vous permet d’avoir tout l’espace de noms * .dev pour le développement (par exemple), sans avoir à saisir individuellement chaque domaine que vous souhaitez résoudre localement dans /etc/hosts
Le problème était que je symlinked le fichier/etc/hosts. Si/etc/hosts est un fichier brut, tout va bien.
Update (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 et je ne suis donc pas sûr du comportement de découverte avec les recherches DNS et les /etc/hosts.
Le résolveur DNS système sur Lion est le processus mDNSResponder.
Vous pensez peut-être "mais mDNSResponder est le répondeur DNS multidiffusion". Tu as raison; c'est ce à quoi il était destiné à l'origine, et il remplit toujours cette fonction. Cependant, sur les versions MacOS plus récentes, il effectue également des recherches d'hôte standard.
Dans Lion, il ne semble pas qu'il relise automatiquement /etc/hosts quand cela change, du moins pas toujours. Tuer mDNSResponder (et permettre son redémarrage automatique) semble résoudre le problème.
Sudo killall mDNSResponder
devrait faire l'affaire.
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 /etc/hosts fichier est un fichier texte de style unix, avec des sauts de ligne comme terminaison plutôt que cr.
L'édition avec TextWrangler ou un éditeur de texte unix doit préserver le fichier.
Si votre fichier est déjà foiré, essayez ceci pour réparer
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 moment, comme je travaillais avec une équipe de développeurs, il est devenu nécessaire d’utiliser réellement .local plutôt que .dev ou .localhost, j’ai trouvé cet article très utile.
iTand.me - Domaines 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 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 éditer/etc/hosts à la place, mais c'est une meilleure alternative que de devoir renommer tous nos serveurs .local.
Ma situation était similaire, mais les retards, d’exactement 5 secondes, ne se produisaient que pour les URL se terminant par ".local". Lors de la visualisation des sites qui se sont terminés par ".dev", il n'y avait aucun retard.
Certains des autres développeurs de mon bureau ont eu ce problème, alors que 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 Terminal et 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 j'avais Back To My Mac activé. Une fois que j’ai désactivé Back To My Mac, le résolveur supplémentaire s’est éloigné et le délai de 5 secondes a disparu.
Avant de passer de Snow Leopard à Lion, j’avais plusieurs entrées spécifiques à une application dans /etc/hosts, comme ça:
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 s'était écoulé avant que la demande ne soit affichée dans le fichier journal et qu'une fois que cela était 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 va vite à nouveau.
Apparemment, cela ajoute des adresses IPv6? Je ne comprends pas très bien, vraiment, mais ça marche.
Wow, quel cauchemar. J'ai lu absolument tout 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 ne fonctionnait 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 à 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 l'éditerait que depuis la ligne de commande en utilisant emacs. Et dieu merci, je n'ai pas eu à utiliser mon propre serveur DNS, comme DNSmasq, pour résoudre le problème.
(Pour être clair, le symptôme qui m'a amené ici à cette question était qu'emacs prenait environ 10 secondes pour démarrer, mais seulement lorsque j'étais en wifi. Si j'éteignais le wifi, les emacs démarreraient instantanément comme prévu.)
Ma solution: mon ordinateur portable a un nom, "terminateur". (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 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 boîte de développement Web ... En combinant diverses suggestions, j'ai opté pour la désactivation du réseau ipv6 et le routage d'ipv6 vers localhost6 ... les choses ont un peu accéléré ...
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 d'entre eux ne semble s'appliquer actuellement (par exemple, mettre plusieurs alias sur une seule ligne me convient parfaitement).
Quoi qu'il en soit, il semble qu'avec Lion, Apple a apporté des changements radicaux à mDNSResponder, qui gère toutes les recherches DNS et (avec au moins Lion) gère également la mise en cache de/etc/hosts. Les recherches fonctionnent également, mais les recherches inversées (par exemple, 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 opérer, mais cela ne fonctionne pas du tout avec/etc/hosts.
À moins bien sûr d’ajouter un alias 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é à la voir. Cela corrige 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