Las búsquedas de DNS fallan con, por ejemplo, 'ping', pero trabaja con 'host'

32

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

Funciona como se esperaba con Linux y, en particular, puedo ejecutar host abc y ping abc (y otras aplicaciones) y todas 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 comando host 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 abc funciona cuando se usa el comando host pero falla con ping (y otras aplicaciones)?

Gracias por leer.

    
pregunta Brian M. Hunt 03.09.2011 - 02:34

10 respuestas

26

Por qué hicieron este cambio, no lo sé, pero me ha vuelto loca por un tiempo.

No por qué las cosas funcionan para el host, pero no hace 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 hacerse eco. La función de búsqueda de nombre de host es solo un efecto secundario del trabajo y se entrega al sistema de resolución recursivo del sistema (creo que no lo he verificado al verificar bibliotecas vinculadas ni nada de ese tipo). El trabajo principal del host es hacer la resolución de nombres DNS, por lo que implementa su propia resolución recursiva.

La resolución recursiva 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>\)/\
                <string>-AlwaysAppendSearchDomains<\/string>/
}' /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

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

Esto agregará el argumento "-AlwaysAppendSearchDomains" al archivo plist de inicio 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 el proceso de mDNSResponder en ejecución, debería verlo ejecutarse con su nuevo argumento:

ps auxww | grep mDNSResponder

(Ayuda a enlace y enlace , donde encontré mis respuestas a este problema.)

    
respondido por el Sigsegv 09.09.2011 - 03:32
8

Desde la página del manual del host (1):

  

AVISO DE Mac OS X

     

El comando del host no usa el nombre del host y la resolución de la dirección o los mecanismos de enrutamiento de consultas DNS utilizados por otros procesos en ejecución   en Mac OS X. Los resultados de las consultas de nombre o dirección impresas por el host pueden diferir de los encontrados por otros procesos que utilizan Mac OS   X nombre nativo y mecanismos de resolución de direcciones. Los resultados de las consultas de DNS también pueden diferir de las consultas que utilizan el DNS de Mac OS X   biblioteca de enrutamiento.

Lamentablemente, no hay información sobre cómo exactamente el comando del host resuelve los nombres de host. Este comportamiento lo hace un poco inútil para la depuración, IMHO.

    
respondido por el Kiezpro 03.09.2011 - 19:50
6

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 del sistema en diferentes plataformas funcionaron de forma diferente a nslookup. A veces, esto produciría resultados bastante diferentes.

Los comandos host y dig se crearon como la "reescritura" para nslookup. Se enlazan estáticamente en las funciones de resolución del sistema. El sistema de resolución del sistema 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 funcionan siempre de la misma manera que el sistema de resolución del sistema para cualquier sistema operativo para el que están diseñados, pero no confían en ello. De esta manera, son excelentes herramientas de diagnóstico en los casos en que el sistema de resolución del sistema no funciona correctamente.

NOTA: Tanto el host como la excavación 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 del host usa la lista de búsqueda en el archivo /etc/resolv.conf; la excavación no lo hace, por lo que siempre se debe otorgar FQDN de excavación para resolver cualquier problema. Ambos comandos son completamente autosuficientes; Por ejemplo, el archivo /etc/resolv.conf es lo único que no está en el archivo binario que utilizan.

mDNSresponder es Bonjour. No he investigado 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 reiniciando mDNSresponder lo solucioné. Nunca he visto este problema en 10.5 - > 10.8 / 10.9 en cualquier otro sistema. Además, las aplicaciones GUI no se vieron afectadas por esto, 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.

    
respondido por el Lamont Peterson 05.02.2014 - 16:57
4

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

enlace

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

    
respondido por el Mike Thomson 23.03.2013 - 22:55
4

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

    
respondido por el Jim 09.01.2015 - 18:13
3

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

    
respondido por el bmike 03.09.2011 - 03:41
2

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

Esto actualiza /etc/resolv.conf y el ping debería funcionar ahora. La actualización de la ruta de búsqueda mediante la edición de /etc/resolv.conf realmente no funciona, pero esto funciona por alguna razón.

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 Preferencias del sistema.

    
respondido por el KETALTHEDON 28.07.2017 - 13:01
1

No tengo suficiente reputación para comentar publicación de Lamont Peterson . El reinicio de mDNSresponder me funcionó en Mac OS X 10.7 (Lion). A diferencia de Lamont Peterson, este problema causó problemas con una aplicación GUI para mí: Safari no pudo resolver los nombres de host públicos o privados. Aquí están 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 unload cierra mDNSresponder y el load lo inicia de nuevo.

Esto resolvió el problema inmediatamente; no se requiere reiniciar.

Puede verificar que se haya reiniciado correctamente usando el comando list :

$ 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. 708 variará 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 mDNSResponderHelper interactúa con mDNSResponder ; Solo he tenido que reiniciar mDNSResponder .

    
respondido por el Setaa 10.02.2018 - 10:53
1

En una línea:

sudo kill $(ps ax | grep mDNSResponder | grep -v grep | grep -v Helper | awk '{ print $1 }')
    
respondido por el Leon Waldman 30.10.2018 - 17:58
0

la nota de los pls sobre los nombres de OSX puede ser no estándar, así que para completarla:

  • Los FQDN se pueden hacer ping
  • 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 abriendo preferencias puedes ver:

    
respondido por el ingconti 20.01.2018 - 16:20

Lea otras preguntas en las etiquetas