Orden de búsqueda de DNS de Mac OSX Lion [cerrado]

96

Después de actualizar a Mac OSX Lion, descubrí que / etc / hosts ya no se busca en primer lugar para la resolución de nombres. Esto conduce a algunos efectos secundarios como:

  1. Las entradas en / etc / hosts se resuelven terriblemente lentas
  2. No puede anular los dominios existentes, p. Ej. 127.0.0.1 www.google.com
  3. Si obtiene entradas de dominio de búsqueda de DHCP, digamos .lan, y algún tipo gracioso configuró localhost.lan en algo más que 127.0.0.1 en el DNS local, ya no podrá comunicarse con su localhost.

¿Este comportamiento es intencionado? ¿Tiene algún sentido? Y lo más importante, ¿cómo puedo volver al antiguo comportamiento?

Meik
fuente
12
Pregunta súper útil: sorpresa, sorpresa, está cerrada como fuera de tema
Sebastian Patten
Al menos no han eliminado el hilo ... todavía. Esto salvó mi tocino. Cambié todos mis hosts de X.local a X.lhost y el problema desapareció. En una nota al margen, soy un gran fanático de xip.io, por ejemplo, foo.127.0.0.1.xip.io
Tim

Respuestas:

78

Creo que lo importante es que Lion maneja los TLD .local de manera diferente porque está reservado para algunas funciones de DNS de multidifusión (utilizadas por Bonjour). La única forma que encontré para resolver este problema es usando un TLD diferente para los hosts de desarrollo (es decir: .dev). Funciona bien para mí, ¡espero que sea útil para otros!

Jean-Baptiste MONIN
fuente
Gracias. Muy útil en verdad.
Cade
5
Mi primer pensamiento fue "cojo". Sin embargo, luego me topé con esta otra publicación de la pila y cambié mi postura: serverfault.com/questions/17255/…
Matt Beckman
Una nota: si usa Chrome para el desarrollo, los dominios de nivel superior no estándar se interpretarán como búsqueda. Es posible que deba hacer algo como .dev.com para que realice una búsqueda de dominio real. No estoy seguro de cómo hacer esto con elegancia.
bbrame
5
@bbrame: Puede introducir su dominio local con el esquema de URL: http://foo.dev/; Después de eso, Chrome se dará cuenta de que foo.deves un dominio y no una consulta.
armas
Alternativamente, puede usar la herramienta dscl para agregar una excepción.
Artur Bodera
51

Con respecto a la anulación de dominios en el archivo de hosts, descubrí que, en algunas circunstancias, Lion consulta la dirección IPv6 de un dominio si detecta que un dominio no es accesible a través de la red IPv4.

Descubrí esto cuando noté algunos anuncios que nunca antes había visto en Snow Leopard porque había redirigido los dominios de anuncios a 127.0.0.1. Encendí Wireshark y noté consultas AAAA(registros DNS IPv6) después de las Aconsultas IPv4 (IPv4). Los servidores de anuncios tienen direcciones IPv6 y pudieron mostrarme su contenido.

La solución a esto es tener un

::1 mydomain.com

entrada para cada

127.0.0.1 mydomain.com

entrada en su archivo de hosts.

Curiosamente, si tiene un servidor web local ejecutándose 127.0.0.1:80y su navegador recibe una respuesta del servidor web (error o no), no AAAAse emite ninguna consulta, ya que parece estar satisfecho de que una conexión TCP era al menos posible.


En una nota relacionada, si hace un uso intensivo del archivo de hosts (para bloqueo de anuncios, desarrollo web local, etc.), es posible que desee considerar ejecutar su propio sistema de resolución de DNS local. Hay un impacto considerable en el disco / CPU por tener que leer /etc/hostsen cada solicitud, por lo que le conviene mantener ese archivo muy ligero.

Una ventaja de ejecutar algo como dnsmasqlocalmente (además del aumento significativo del rendimiento) es que puede redirigir dominios completos de nivel superior a su máquina local. Esto le permite tener todo el espacio de nombres * .dev para el desarrollo (por ejemplo), sin tener que ingresar individualmente cada dominio que desea resolver localmente en/etc/hosts

armas
fuente
3
Muchas gracias por esto. Esperar entre 10 y 30 segundos para probar los cambios en mi código me estaba volviendo loco y me ahorraste un montón de tiempo al no tener que resolver esto yo mismo.
Zack Angelo
1
Tuve el mismo problema, ¡y esto solucionó mi problema de inmediato! Agradable.
cstrat
1
+1 Este es un gran dato para cualquiera que busque "por qué mi archivo de hosts no funciona". ¡Puedo hacer esa pregunta aquí solo para que pueda poner la misma respuesta allí y facilitar la búsqueda a través de un motor de búsqueda!
cape1232
No debería haber un aumento apreciable en la E / S del disco debido a la lectura /etc/hosts: el sistema operativo almacenará en caché el archivo si se usa con frecuencia.
Dan Pritts
Los usuarios cuyas LAN sean compatibles con IPv6 (¡es casi 2016, después de todo!) Encontrarán este problema desde ahora hasta que IPv4 desaparezca por completo ... ¡o hasta que Apple detecte el problema y lo resuelva internamente! La respuesta de Jean-Baptiste también debe tenerse en cuenta (es decir, use .dev en lugar de .local para sus entornos de desarrollo).
creaciones inigualables
17

El problema fue que hice un enlace simbólico al archivo / etc / hosts. Si / etc / hosts es un archivo simple, todo está bien.

Meik
fuente
1
Estoy teniendo el mismo problema. Sin embargo, mi archivo / etc / hosts es un archivo normal. Cualquier ayuda en esto sería apreciada.
Matt
4
Este parece haber sido mi problema también. Tenía un enlace simbólico a un archivo en mi carpeta de Dropbox, que solía funcionar y que pensé que era muy inteligente. Parece que Apple ya no encuentra esto inteligente. También hice un reinicio real completo usando Option-restart después de moverlo de un enlace simbólico a un archivo real. Todo parece feliz ahora.
Tom S.
2
Las entradas en un archivo de hosts con enlaces simbólicos están bien si no pueden resolverse de otra manera, esto indica que un archivo de hosts con enlaces simbólicos solo se verifica cuando una dirección no se puede resolver de otra manera. Cuando el archivo de hosts es un archivo normal, se verifica antes que cualquier otra forma de resolución. Por lo tanto, si necesita anular dominios que realmente tienen entradas DNS válidas, su archivo de hosts debe ser un archivo y no un enlace simbólico.
cerberos
1
Para el registro, este sigue siendo el caso en Mavericks (10.9), sería útil si alguien pudiera confirmar lo que hace Yosemite…
William Turrell
1
Yosemite también lo hace, simplemente se encontró con este problema. Este es un comportamiento extremadamente extraño.
Vytautas Gimbutas
14

Actualización (2): OSX 10.10.5 trae el regreso de mDNSResponder .

Actualización: OSX 10.10 Yosemite ha reemplazado mDNSResponder con "discoveryd". No he actualizado, así que no estoy seguro del comportamiento descubierto con búsquedas de DNS y/etc/hosts .

El sistema de resolución de DNS en Lion es el mDNSResponder proceso.

Puede estar pensando "pero mDNSResponder es el respondedor dns de multidifusión". Tienes razón; para eso fue originalmente, y aún cumple esta función. Sin embargo, en las versiones más recientes de MacOS, también realiza búsquedas de host estándar.

En Lion, no parece volver a leerse automáticamente /etc/hostscuando cambia, al menos no siempre. Matar mDNSResponder(y permitir que se reinicie automáticamente) parece solucionar el problema.

sudo killall mDNSResponder

debería hacer el truco.

a continuación está mi respuesta original para la posteridad. Supongo que aún podría ser un problema en algunos casos.

Asegúrese de que su /etc/hosts archivo sea un archivo de texto de estilo Unix, con avances de línea como final en lugar de cr.

La edición con TextWrangler o un editor de texto Unix debería preservar el archivo.

Si su archivo ya está estropeado, intente esto para solucionarlo

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édito por esta corrección a:

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

Dan Pritts
fuente
Esto podría resolver un problema con un demonio de resolución de DNS bloqueado, pero no resuelve el problema de resolver hosts en direcciones IP de LAN que se encuentran a menudo en los entornos de desarrollo. La respuesta de @guns, a continuación, será la solución adecuada para la mayoría de las personas que encuentren esta pregunta en la búsqueda; aunque Jean-Baptiste-MONIN también tiene una respuesta con méritos.
creaciones inigualables
Puede resolver el problema de que los cambios en / etc / hosts no se noten.
Dan Pritts
Estoy usando High Sierra y esta respuesta resuelve el problema de alias, gracias
Absolutkarlos
4

He tenido este problema por un tiempo, ya que estoy trabajando con un equipo de desarrolladores, se hizo necesario usar .local en lugar de .dev o .localhost, este artículo me pareció muy útil.

iTand.me - Dominios locales de Lion y hosts, etc.

En resumen;

Pero si tiene que usar .local, la solución más elegante que he encontrado es la utilidad dscl. Usarlo es muy sencillo. Para agregar un host llamado mydev.local y apuntarlo al localhost, simplemente haga esto:

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

Para ver todos los hosts definidos actualmente y sus IP

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

Y para eliminar un host:

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

En general, es bastante sencillo y funciona bien. Todavía preferiría poder editar / etc / hosts, pero esta es una mejor alternativa a tener que cambiar el nombre de todos nuestros servidores .local.

Abierto sintonizado
fuente
3
Al agregar un nombre de host de esta manera, aparentemente no hace nada. No se puede hacer ping a la dirección. Ejemplo: sudo dscl localhost -create / Local / Default / Hosts / test1 IPAddress 127.0.0.1 ping test1 ping: no se puede resolver test1: host desconocido
oligofren
3

Antes de pasar de Snow Leopard a Lion, tenía varias entradas específicas de aplicaciones /etc/hosts, como esta:

127.0.0.1 foo.bar.local

Después de la actualización, la carga de mis aplicaciones locales fue MUY lenta. Noté que el retraso ocurrió antes de que la solicitud apareciera en el archivo de registro, y que una vez que lo hizo, la aplicación en sí fue tan rápida como de costumbre.

Ahora tengo dos líneas por aplicación, así:

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

... y todo vuelve a ser rápido.

¿Aparentemente esto agrega direcciones IPv6? No lo entiendo del todo, de verdad, pero funciona.

Nathan Long
fuente
Nada más funcionó para mí, pero esto funcionó en un instante, ¡gracias Nathan!
foiseworth
3

Mi situación era similar, pero los retrasos, de exactamente 5 segundos, solo ocurrieron para las URL que terminan en '.local'. Al ver sitios que terminaron en '.dev', no hubo demoras.

Algunos de los otros desarrolladores de mi oficina tenían este problema, mientras que otros no. Esperaba una solución simple y no quería cambiar el nombre del sitio a '.local' debido a otras dependencias.

Ejecuté el siguiente comando en la Terminal y diferencié mi salida con algunos otros usuarios en la oficina.

scutil --dns

Esta sección fue la única diferencia:

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

Mi Mac estaba vinculada a mi cuenta de iCloud y tenía habilitado Volver a mi Mac. Una vez que desactivé Back To My Mac, la resolución adicional desapareció y el retraso de 5 segundos desapareció.

Paul J. Martínez
fuente
1

Vaya, qué pesadilla. He leído absolutamente todo sobre este tema y todo lo que se ha sugerido hasta ahora se acerca mucho a lo que estaba experimentando, pero ninguna de las soluciones funcionó para mí.

Y descubrí por qué.

A diferencia de otros, no estaba usando / etc / hosts para configurar dominios locales. Mi archivo / etc / hosts estaba en stock y solo contenía las entradas necesarias para la interfaz de bucle invertido y el host de transmisión. Además, era un archivo Unix correctamente codificado, ya que soy el tipo de persona que solo lo editaría desde la línea de comandos usando emacs. Y, gracias a Dios, no tuve que recurrir a ejecutar mi propio servidor DNS como DNSmasq para solucionar el problema.

(Para ser claros, el síntoma que me trajo aquí a este problema fue que emacs tardó unos 10 segundos en iniciarse, pero solo cuando estaba conectado a wifi. Si apagaba el wifi, emacs se iniciaría instantáneamente como se esperaba).

Mi solución: mi computadora portátil tiene un nombre, "terminador". (Sí, su exterior de aluminio brillante me hizo pensar en el personaje de Arnold Schwarzenegger). Solo necesitaba agregar entradas a / etc / hosts para el nombre de la máquina en sí:

127.0.0.1   terminator
::1         terminator

Encontré el nombre de mi host ejecutando un comando simple en la terminal:

hostname

... que volvió con la salida: "terminador". Después de cambiar / etc / hosts para que contenga esas dos entradas, emacs ahora puede resolver rápidamente el nombre de mi computadora portátil.

Espero que esto ayude a alguien.

pohl
fuente
1
esto parece haber funcionado para mí en este momento. Veremos si esto se mantiene. Estoy EMOCIONADO de que hayas descubierto esto, porque he visto surgir este problema de manera intermitente sin advertencia.
Jeremy Carlson
Disparar. Esta no es una resolución permanente para mí. Problema de vuelta. Eso sí, mientras releo esto, mi problema no es tuyo ...
Jeremy Carlson
0

Tuve problemas de velocidad al usar OSX Lion como caja de desarrollo web ... Usando una combinación de sugerencias, recurrí a deshabilitar la red ipv6 y enrutar ipv6 a localhost6 ... las cosas se aceleraron un poco ...

sudo networksetup -setv6off Ethernet

/ etc / hosts ...

127.0.0.1    localhost
127.0.0.1    dev.aliasdomain.com
... 
::1          localhost6 
Eddie B
fuente
0

Creo que ha habido algunas correcciones de errores. He visto muchos problemas mencionados y ninguno de ellos parece aplicarse actualmente (por ejemplo, poner varios alias en una sola línea ahora funciona bien para mí).

En cualquier caso, parece que con Lion, Apple realizó algunos cambios drásticos en mDNSResponder que maneja todas las búsquedas de DNS y (con Lion al menos) también maneja el almacenamiento en caché de / etc / hosts. Para mí, las búsquedas hacia adelante también funcionan. Pero las búsquedas inversas (por ejemplo, buscar 1.2.3.4 en lugar de google.com) no funcionan.

Después de mucho dolor, parece que mDNSResponder convierte esta búsqueda en 4.3.2.1.in-addr.arpa y realiza una búsqueda de nombre. Esta puede ser la forma en que DNS prefiere operar, pero no funciona en absoluto con / etc / hosts.

A menos que, por supuesto, agregue un alias de 4.3.2.1.in-addr.arpa para cada host, donde 4.3.2.1 es la dirección IP en el orden opuesto al que está acostumbrado a ver. Esto arregla todo para mí. Aquí hay un ejemplo de entrada de / etc / hosts:

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

Thomasafine
fuente