Ordre de recherche DNS Mac OSX Lion [fermé]


96

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.


12
Question super utile - surprise, surprise, c'est fermé car hors sujet
Sebastian Patten

Au moins, ils n'ont pas encore supprimé le fil de discussion. Cela a sauvé mon bacon. J'ai changé tous mes hôtes de X.local à X.lhost et le problème a disparu. Par ailleurs, je suis un grand fan de xip.io, par exemple foo.127.0.0.1.xip.io
Tim

Réponses:


78

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!


Je vous remercie. Très utile en effet.
Cade

5
Ma première pensée a été "boiteuse". Cependant, je suis ensuite tombé sur cet autre poteau de pile et j'ai changé ma position: serverfault.com/questions/17255
Matt Beckman

Une note - si vous utilisez Chrome pour le développement, les domaines de premier niveau non standard seront interprétés comme une recherche. Vous devrez peut-être faire quelque chose comme .dev.com pour lui faire effectuer une véritable recherche de domaine. Je ne sais pas comment faire cela avec élégance.
bbrame

5
@bbrame: Vous pouvez entrer votre domaine local avec le schéma d'URL: http://foo.dev/; Après cela, Chrome se rendra compte qu'il foo.devs'agit d'un domaine et non d'une requête.
canons

Vous pouvez également utiliser l'outil dscl pour ajouter une exception.
Artur Bodera

51

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


3
Merci beaucoup pour cela. Attendre 10 à 30 secondes pour tester les modifications de mon code me rendait fou et vous m'avez fait gagner beaucoup de temps en n'ayant pas à comprendre cela moi-même.
Zack Angelo

1
J'ai eu le même problème, et cela a résolu mon problème immédiatement! Agréable.
cstrat

1
+1 C'est une excellente information pour tous ceux qui recherchent "pourquoi mon fichier hosts ne fonctionne pas". Je peux poser cette question ici juste pour que vous puissiez y mettre la même réponse et la rendre plus facile à trouver via un moteur de recherche!
cape1232

Il ne devrait pas y avoir d'augmentation notable des E / S disque suite à la lecture /etc/hosts- le système d'exploitation mettra en cache le fichier s'il est utilisé fréquemment.
Dan Pritts

Les utilisateurs dont les réseaux locaux prennent en charge IPv6 (nous sommes presque 2016, après tout!) Rencontreront ce problème à partir de maintenant jusqu'à ce qu'IPv4 soit complètement parti ... ou jusqu'à ce qu'Apple découvre le problème et le résout en interne! La réponse de Jean-Baptiste doit également être prise en compte (c'est-à-dire, utilisez .dev au lieu de .local pour vos environnements de développement).
uncivaledcreations

17

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


1
J'ai le même problème. Cependant, mon fichier / etc / hosts est un fichier normal. Toute aide à ce sujet serait appréciée.
matt

4
Cela semble aussi avoir été mon problème. J'avais un lien symbolique vers un fichier dans mon dossier Dropbox, qui fonctionnait auparavant et que je trouvais très intelligent. Il semblerait qu'Apple ne trouve plus cet astucieux. J'ai également fait un vrai redémarrage complet en utilisant Option-restart après l'avoir déplacé d'un lien symbolique vers un vrai fichier. Tout semble heureux maintenant.
Tom S.

2
Les entrées dans un fichier d'hôtes lié par un lien symbolique sont correctes si elles ne peuvent pas être résolues autrement, cela indique qu'un fichier d'hôtes lié par un lien symbolique n'est vérifié que lorsqu'une adresse ne peut pas être résolue autrement. Lorsque le fichier hosts est un fichier normal, il est vérifié avant toute autre forme de résolution. Donc, si vous devez remplacer des domaines qui ont réellement des entrées DNS valides, votre fichier d'hôtes doit être un fichier et non un lien symbolique.
cerberos

1
Pour mémoire, c'est toujours le cas dans Mavericks (10,9), ce serait utile si quelqu'un pouvait confirmer ce que fait Yosemite…
William Turrell

1
Yosemite le fait aussi, vient de rencontrer ce problème. C'est un comportement extrêmement étrange.
Vytautas Gimbutas

14

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


Cela peut résoudre un problème avec un démon de résolution DNS en panne, mais cela ne résout pas le problème de résolution des hôtes en adresses IP LAN souvent rencontrées dans les environnements de développement. La réponse @guns, ci-dessous, sera la bonne solution pour la plupart des gens qui trouvent cette question dans la recherche; même si Jean-Baptiste-MONIN a également une réponse méritée.
uncivaledcreations

Cela peut résoudre le problème des modifications apportées à / etc / hosts qui ne sont pas remarquées.
Dan Pritts

J'utilise high sierra et cette réponse résout le problème d'alias, merci
Absolutkarlos

4

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.


3
Lorsque vous ajoutez un nom d'hôte de cette façon, cela ne fait apparemment rien. Impossible de cingler l'adresse. Exemple: sudo dscl localhost -create / Local / Default / Hosts / test1 IPAddress 127.0.0.1 ping test1 ping: impossible de résoudre test1: hôte inconnu
oligofren

3

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.


Rien d'autre n'a fonctionné pour moi mais cela a fait en un instant - merci Nathan!
foiseworth

3

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.


1

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.


1
cela semble avoir fonctionné pour moi tout à l'heure. Nous verrons si cela tient. Je suis ravi que vous ayez compris cela, car j'ai vu par intermittence ce problème surgir sans avertissement.
Jeremy Carlson

Tirer. Ce n'est pas une résolution permanente pour moi. Problème de retour. Rappelez-vous, en relisant ceci, mon numéro n'est pas le vôtre ...
Jeremy Carlson

0

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 

0

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.