Las búsquedas de DNS fallan con, por ejemplo, `ping`, pero funcionan con `host`

No sé por qué hicieron este cambio, pero me ha vuelto loco por un tiempo.

No sé por qué las cosas funcionan para host, pero no para ping, pero creo que tiene que ver con la naturaleza de estas dos utilidades. Ping es una utilidad de diagnóstico simple (aunque muy útil) para colocar paquetes en el cable que deberían devolverse a usted. La funcionalidad de búsqueda de nombre de host es solo un efecto secundario del trabajo y se entrega al solucionador recursivo del sistema (creo, no lo he verificado al verificar las bibliotecas vinculadas ni nada por el estilo). El trabajo principal del host es hacer la resolución de nombres DNS, por lo que implementa su propia resolución recursiva.

El solucionador recursivo de Apple es mDNSResponder. Por alguna razón, la versión de mDNSResponder en Lion necesita la opción de línea de comando "-AlwaysAppendSearchDomains" para comportarse como lo hizo en Snow Leopard (al menos).

Aquí hay una forma rápida de solucionarlo:

sudo sed -i .orig '/ProgramArguments/,/<\/array>/ {
s/\(<string>-launchd<\/string>\)/\1\
                <string>-AlwaysAppendSearchDomains<\/string>/
}' /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

(Debe haber dos caracteres de tabulación al comienzo de la penúltima línea anterior, pero no pude averiguar cómo hacer que este pequeño editor inserte tabulaciones, así que agregué 16 espacios. Cualquiera de los dos debería funcionar, pero las tabulaciones ajusta mejor al espacio del archivo original).

Esto agregará el argumento "-AlwaysAppendSearchDomains" al archivo plist de inicio de mDNSResponder (y guardará una copia de respaldo), pero como esto está controlado por launchd, se debe indicar a ese sistema que reinicie mDNSResponder.

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Ahora, si verifica su proceso mDNSResponder en ejecución, debería verlo ejecutándose con su nuevo argumento:

ps auxww | grep mDNSResponder

(Apoyos a http://www.makingitscale.com/2011/fix-for-broken-search-domain-solution-in-osx-lion.html y http://kavassalis.com/2011/07/wtf-bug -in-os-x-10-7/ , donde encontré mis respuestas a este problema).

Desde la página del comando man host(1):

AVISO Mac OS X

El comando host no utiliza la resolución de dirección y nombre de host o los mecanismos de enrutamiento de consulta de DNS utilizados por otros procesos que se ejecutan en Mac OS X. Los resultados de las consultas de nombre o dirección impresos por host pueden diferir de los encontrados por otros procesos que utilizan Mac. Mecanismos nativos de resolución de nombres y direcciones de OS X. Los resultados de las consultas DNS también pueden diferir de las consultas que utilizan la biblioteca de enrutamiento DNS de Mac OS X.

Desafortunadamente, no hay información sobre cómo resuelve exactamente el comando host los nombres de host. Este comportamiento lo hace algo inútil para la depuración, en mi humilde opinión.

Historial básico... nslookup era el comando, pero tenía su propia implementación de todas sus rutinas de resolución. Lo que comenzó a suceder fue que los solucionadores de sistemas en diferentes plataformas funcionaban de manera diferente a nslookup. A veces, esto produciría algunos resultados bastante diferentes.

Los comandos host y dig se crearon como "reescritura" para nslookup. Se vinculan estáticamente en las funciones de resolución del sistema. El sistema de resolución es una colección de funciones en la biblioteca C estándar de un sistema UNIX o similar (en Mac OS X, estas funciones son parte de la biblioteca netdb). Al hacer esto, los comandos host y dig siempre funcionan de la misma manera que lo hace el sistema de resolución para cualquier sistema operativo para el que estén creados, pero no dependen de él. De esta manera, son excelentes herramientas de diagnóstico en los casos en que el resolver del sistema no funciona correctamente.

NOTA: Host y dig leen la lista de servidores de nombres de /etc/resolv.conf a menos que se les dé un servidor de nombres específico para hablar. Solo el comando host usa la lista de búsqueda en el archivo /etc/resolv.conf; dig no lo hace, por lo que siempre se debe proporcionar dig FQDN para resolver cualquier problema. Por lo demás, ambos comandos son totalmente autosuficientes; por ejemplo, el archivo /etc/resolv.conf es lo único que no está en el archivo binario que utilizan.

mDNSresponder es Bonjour. No lo he profundizado demasiado, pero sospecho que esta configuración no soluciona esto o, al menos, no directamente. Acabo de experimentar este mismo problema en Mac OS X 10.9.1 y simplemente reiniciar mDNSresponder lo solucionó. Nunca antes había visto este problema en 10.5 -> 10.8/10.9 en ningún otro sistema. Además, las aplicaciones GUI no se vieron afectadas por él, solo las herramientas de línea de comandos, como ping y ssh, se rompieron.

Si encuentro tiempo para investigar un poco más en la biblioteca, veré si puedo encontrar una explicación más completa.

He creado un script de shell para automatizar la solución (y un desinstalador si lo necesita más tarde), aquí:

https://github.com/michthom/AlwaysAppendSearchDomains

Esto fue para dar a conocer a los usuarios menos técnicos en el trabajo que podrían rehuir la edición manual de archivos del sistema.

.local está reservado para multidifusión. Los servidores mDNS y DNS en la misma red que usan .local pueden ser problemáticos.

El host está agregando el sufijo .local dns. Ping no lo es. Si encuentra esto desconcertante, puede agregar .local como sufijo predeterminado en las preferencias del sistema de red y el sistema lo agregará cuando intente resolver los nombres de host.

En caso de que haya intentado todo lo anterior y nada haya funcionado, puede agregar sus servidores de nombres y rutas de búsqueda aSystem Preferences>Network>Advance(bottom right of the window)>DNS tab

Esto actualiza /etc/resolv.conf y ping ahora debería funcionar. Actualizar la ruta de búsqueda editando /etc/resolv.conf realmente no funciona, pero por algún motivo sí lo hace.

ACTUALIZAR:

La edición de /etc/resolv.conf no funciona porque el sistema operativo vuelve a escribir el archivo según la configuración del panel de preferencias del sistema.

Carezco de suficiente reputación para comentar la publicación de Lamont Peterson . Reiniciar mDNSresponder me funcionó en Mac OS X 10.7 (Lion). A diferencia de Lamont Peterson, este problema me causó problemas con una aplicación GUI: Safari no pudo resolver los nombres de host públicos o privados. Estos son los pasos específicos que hice y que sospecho que Lamont Peterson también hizo:

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSresponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSresponder.plist

El unloadapaga mDNSresponder y loadlo vuelve a encender.

Esto resolvió el problema de inmediato; no es necesario reiniciar.

Puede verificar que se haya reiniciado correctamente usando el listcomando:

$ sudo launchctl list | grep '^PID\|mDNSResponder'
PID     Status  Label
708     -       com.apple.mDNSResponder
-       0       com.apple.mDNSResponderHelper

La presencia de un ID de proceso (PID) significa que se está ejecutando. 708variará según lo asigne el sistema operativo. Si el estado muestra algo que no sea un guión o un cero, algo salió mal.

no sé cómo mDNSResponderHelperinteractúa con mDNSResponder; Solo he tenido que reiniciar mDNSResponder.

En una línea:

sudo kill $(ps ax | grep mDNSResponder | grep -v grep | grep -v Helper | awk '{ print $1 }')

Tenga en cuenta que los nombres de OSX pueden no ser estándar, por lo que para completar:

• Se puede hacer ping a FQDN
• se puede hacer ping a los nombres en los archivos "hosts"

Los nombres de Mac NO son en general: se deben hacer dos arreglos: a) cambiar los espacios a "-" b) agregar .local

entonces, por ejemplo, mi Mac: MacBook Pro de ingconti

se podrá hacer ping en: ingcontis-MacBook-Pro.local

Y abriendo preferencias puedes ver: