versiones ultima sistemas sierra puedo pro operativos mojave macbook mac high actualizar macos dns osx-lion hosts-file

macos - ultima - Orden de búsqueda de Mac OSX Lion DNS



sistemas operativos mac versiones (10)

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

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

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

Usted puede estar pensando "pero mDNSResponder es el respondedor de DNS multidifusión". Tienes razón; para eso era originalmente, y todavía cumple esta función. Sin embargo, en las versiones más nuevas de MacOS también realiza búsquedas de host estándar.

En Lion, no parece volver a leer automáticamente /etc/hosts cuando cambia, al menos no siempre. La eliminación del mDNSResponder (y su reinicio automático) 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 sea ​​un archivo de texto de estilo Unix, con avances de línea como terminación en lugar de cr.

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

Si su archivo ya está dañado, intente 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 solución para:

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

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 lleva a algunos efectos secundarios como:

  1. Las entradas en / etc / hosts se resuelven dolorosamente lentas
  2. No puede anular dominios existentes, por ejemplo, 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 otra cosa, entonces 127.0.0.1 en el DNS local ya no puede llegar a su servidor local.

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


Antes de pasar de Snow Leopard a Lion, tuve varias entradas específicas de la aplicación en /etc/hosts , como esta:

127.0.0.1 foo.bar.local

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

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

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

... y todo es rápido de nuevo.

Aparentemente esto agrega direcciones IPv6? No lo entiendo, realmente, pero funciona.


Creo que ha habido algunas correcciones de errores. He visto muchos problemas mencionados, y ninguno de ellos parece aplicarse actualmente (por ejemplo, poner múltiples 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 la caché de / etc / hosts. Para mí, las búsquedas hacia adelante también funcionan ahora. Pero las búsquedas inversas (por ejemplo, buscar 1.2.3.4 en vez 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. Puede que así sea como 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 verlo. Esto arregla todo para mí. Aquí hay una entrada de ejemplo / etc / hosts:

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


Creo que le importa que Lion maneje el TLD local de forma 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 usar un TLD diferente para los hosts de desarrollo (es decir: .dev). ¡Funciona bien para mí, espero que sea útil para otros!


El problema fue que enlacé el archivo / etc / hosts. Si / etc / hosts es un archivo simple, todo está bien.


En lo que respecta a la anulación de dominios en el archivo de hosts, he encontrado que, en algunas circunstancias, Lion consulta la dirección IPv6 de un dominio si detecta que un dominio no se puede acceder a través de la red IPv4.

Descubrí esto cuando noté algunos anuncios que nunca había visto antes en Snow Leopard porque redirigí los dominios de anuncios a 127.0.0.1 . Encendí Winshark y noté las consultas AAAA (registros DNS IPv6) después de las consultas IPv4 A (IPv4). De hecho, los servidores de anuncios tienen direcciones IPv6 y pudieron brindarme 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 en 127.0.0.1:80 y su navegador recibe una respuesta del servidor web (error u otro), no se emite ninguna consulta AAAA , ya que parece estar satisfecho de que una conexión TCP estaba en menos posible.

En una nota relacionada, si haces un uso intensivo del archivo hosts (para el bloqueo de anuncios, desarrollo web local, etc.), es posible que desees buscar la ejecución de tu propia resolución local de DNS. Se produce un considerable daño de disco / CPU por tener que leer /etc/hosts en cada solicitud, por lo que le conviene mantener el archivo muy ligero.

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


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

iTand.me - Dominios locales del león y anfitriones 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 señalarlo al localhost, simplemente haz 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, bastante sencillo y funciona bien. Aún así, preferiría poder editar / etc / hosts, pero esta es una mejor alternativa que tener que cambiar el nombre de todos nuestros servidores .local.


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 demora.

Algunos de los otros desarrolladores en mi oficina tuvieron 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 Terminal y di salida a 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 Back To My Mac habilitado. Una vez que desactivé Volver a mi Mac, la resolución adicional desapareció y la demora de 5 segundos desapareció.


Tuve problemas de velocidad con OSX Lion como una caja de desarrollo web ... Utilicé una combinación de sugerencias para deshabilitar las redes 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


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

Y descubrí por qué.

A diferencia de otros, yo no estaba usando / etc / hosts para configurar dominios locales. Mi archivo / etc / hosts era estándar, conteniendo solo las entradas necesarias para la interfaz loopback y el host broadcast. Además, era un archivo Unix correctamente codificado, ya que soy el tipo de persona que solo edita eso desde la línea de comando usando emacs. Y, gracias a Dios, no tuve que recurrir a 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 comenzar, pero solo cuando estaba en wifi. Si apagaba el wifi, emacs se iniciaba instantáneamente como se esperaba).

Mi solución: mi computadora portátil tiene un nombre, "terminator". (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: "terminator". 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.