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

Estoy usando pfSense 2.0rc3, y lo configuré como un reenviador de DNS y habilité "Registrar arriendos DHCP en el reenviador de DNS" y entiendo que son todas las configuraciones apropiadas para obtener el servidor DNS para búsquedas locales.

Funciona como se esperaba con Linux y, en particular, puedo ejecutar host abcy ping abc(y otras aplicaciones) y todos funcionan como se esperaba.

Sin embargo, en Mac OS X Lion 10.7 no funciona como se esperaba. En particular, solo las búsquedas con el hostcomando parecen funcionar, es decir

$ ping abc
ping: cannot resolve abc: Unknown host

$ host abc
abc.local has address 192.168.1.128

$ ping abc.local
ping: cannot resolve abc.local: Unknown host

$ host abc.local
abc.local has address 192.168.1.128

¿Por qué la búsqueda de abctrabajo cuando se usa el hostcomando pero falla ping(y otras aplicaciones)?

Gracias por leer.

No sé por qué hicieron este cambio, pero me volvió loco por un tiempo.

No sé por qué las cosas funcionan para el host, pero no para hacer 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 soltar paquetes en el cable que debería recibir un eco. La funcionalidad de búsqueda de nombres de host es solo un efecto secundario del trabajo y se transfiere a la resolución recursiva del sistema (creo que no lo he verificado al comprobar 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 propio resolutor recursivo.

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

(Debería haber dos caracteres de tabulación al comienzo de la penúltima línea anterior, pero no pude encontrar la manera de hacer que este pequeño editor inserte pestañas, así que agregué 16 espacios. Cualquiera debería funcionar, pero las pestañas se 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 dado que esto está controlado por launchd, se debe indicar al 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 comprueba su proceso mDNSResponder en ejecución, debería verlo ejecutándose con su nuevo argumento:

ps auxww | grep mDNSResponder

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

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

AVISO DE Mac OS X

El comando del host no utiliza el nombre del host y la resolución de la dirección ni los mecanismos de enrutamiento de consultas DNS utilizados por otros procesos que se ejecutan en Mac OS X. Los resultados de las consultas de nombre o dirección impresos por el host pueden diferir de los encontrados por otros procesos que utilizan el Mac Mecanismos de resolución de direcciones y nombres nativos 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 exactamente el comando del host resuelve los nombres de host. Este comportamiento lo hace algo inútil para la depuración, en mi humilde opinión.

Historia básica ... 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 del sistema en diferentes plataformas funcionaban de manera diferente a nslookup. A veces, esto produciría algunos resultados bastante diferentes.

Los comandos host y dig fueron creados como "reescribir" para nslookup. Se enlazan 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 a UNIX (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 solucionador del sistema para cualquier sistema operativo para el que estén diseñados, pero no dependen de él. De esta manera, son excelentes herramientas de diagnóstico en los casos en que la resolución del sistema no funciona correctamente.

NOTA: el host y la excavación leen la lista de servidores de nombres de /etc/resolv.conf a menos que se les proporcione 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 eso siempre se debe dar dig FQDN para resolver cualquier cosa. Ambos comandos son completamente autosuficientes; por ejemplo, el archivo /etc/resolv.conf es lo único que no está en el archivo binario que usan.

mDNSresponder es Bonjour. No lo he profundizado demasiado, pero sospecho que esta configuración no está solucionando 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ó por mí. 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 se rompieron las herramientas de línea de comandos, como ping y ssh.

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

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

https://github.com/michthom/AlwaysAppendSearchDomains

Esto era para entregar a los usuarios menos técnicos en el trabajo que podrían evitar editar manualmente los archivos del sistema.

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

El anfitrión 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 funcionó, 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 esto lo hace por alguna razón.

ACTUALIZAR:

Editar /etc/resolv.conf no funciona porque el sistema operativo reescribe el archivo en función de la configuración del panel de Preferencias del sistema.

Me falta suficiente reputación para comentar sobre la publicación de Lamont Peterson . Reiniciar mDNSresponder funcionó para mí 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

Los unloadApaga mDNSResponder y los loadél para arriba comienza de nuevo.

Esto resolvió el problema de inmediato; No se requiere reiniciar.

Puede verificar que se haya reiniciado correctamente utilizando 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 más que un guión o cero, algo salió mal.

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

En una linea:

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

la nota de pls sobre los nombres de OSX puede ser no estándar, por lo tanto, para completar:

• FQDN son pingable
• los nombres en los archivos "hosts" se pueden hacer ping

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

así, por ejemplo, mi Mac: el MacBook Pro de ingconti

será pingable en: ingcontis-MacBook-Pro.local

Y las preferencias de apertura se pueden ver: