La búsqueda de nombre DNS (era SSH) no funciona después de la actualización de Snow Leopard

Creo que esto comenzó con la actualización de Snow Leopard. Limpió el directorio .ssh, aún teniendo el problema.

~: uname -a
Darwin california-example-com.local 10.0.0 Darwin Kernel Versión 10.0.0: viernes 31 de julio 22:47:34 PDT 2009; raíz: xnu-1456.1.25 ~ 1 / RELEASE_I386 i386

~: ssh -V
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 de marzo de 2009

~: ls -l ~ / .ssh

~: nslookup nevada
Servidor: 10.94.62.3
Dirección: 10.94.62.3 # 53

Nombre: nevada.example.com
Dirección: 10.94.62.3

~: ssh nevada
ssh: no se pudo resolver el nombre de host nevada: nodename ni servname proporcionados, o no se conocen

Me encontré exactamente con el mismo problema y encontré un hilo sobre una Mac mini que tenía problemas de DNS en los debates de Apple extremadamente útil.

El quid de la cuestión: mDNSResponder parece cambiar ocasionalmente el orden de los servidores DNS que consulta y, por lo tanto, si consulta primero los servidores DNS de su ISP, no obtendrá un registro adecuado (o si está utilizando DNS dividido obtendrá tu IP pública).

La mejor solución para esto es asegurarse (como lo hizo) de que solo los servidores DNS necesarios se enumeran en la configuración de DNS. Esto puede requerir la eliminación de los servidores ISP DNS de su DHCP (como tuve que hacer también; todas las solicitudes se envían a través del servidor DNS local de todos modos).

La razón por la que a las utilidades les gusta digy nslookuptendrán éxito de manera normal es porque están usando BIND y /etc/resolv.confdirectamente a diferencia del resto del sistema operativo.

Como referencia en Snow Leopard, el caché DNS ahora está almacenado por mDNSResponder y para borrarlo, debe reiniciar el proceso usando sudo killall -HUP mDNSResponder. Puede obtener más información (registro, volcado del estado interno, etc.) utilizando diferentes indicadores para el killallcomando.

"sudo killall -USR1 mDNSResponder" to enable operation logging.
"sudo killall -USR2 mDNSResponder" to enable packet logging.
"sudo killall -HUP mDNSResponder" to clear the DNS cache.
"sudo killall -INFO mDNSResponder" to dump mDNSRepsonder's internal state.

Fuente: Snoop Dogg en ese mismo hilo.

tuvimos problemas como este:

host example.com     <<< WORKED
ping example.com     <<< FAILED

Resuelto con algo como esto:

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

Las aplicaciones en Mac OS X no utilizan el mismo mecanismo para DNS que "host / dig / nslookup".

El uso de "host / dig / nslookup" fue útil para determinar que esto no era un problema de red. Fue un problema con el sistema local resuelto con los comandos anteriores.

He experimentado el mismo problema ... Y aunque reiniciar mDNSResponder parece "funcionar", reiniciarlo un par de veces cada hora es una mierda.

Entonces, por ahora, he "resuelto" el problema ejecutando dnsmasq localmente. Para hacer eso:

• Construya dnsmasq (descargue el tgz y makeo brew install dnsmasq)
• Pon esto en un dnsmasq.confarchivo:

resolv-file = resolv.conf
usuario = nadie
grupo = nadie
interfaz = lo0
tamaño de caché = 1024

• Ponga esto en un resolv.confarchivo que esté en el mismo directorio que el dnsmasq.confarchivo (nb: not /etc/resolv.conf ):

servidor de nombres 8.8.8.8
servidor de nombres 4.2.2.1
servidor de nombres 4.2.2.2

• Corre dnsmasqcon sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf. La salida debería ser similar a:

...
dnsmasq: lectura resolv.conf
dnsmasq: uso del servidor de nombres 4.2.2.1 # 53
dnsmasq: uso del servidor de nombres 4.2.2.2 # 53
dnsmasq: uso del servidor de nombres 8.8.8.8 # 53
dnsmasq: read / etc / hosts - 6 direcciones

• Abra Preferencias de red y asegúrese de que 127.0.0.1sea ​​el único servidor DNS (preferencias de red -> avanzado -> DNS -> agregar 127.0.0.1)

Las cosas deberían comenzar a funcionar bien nuevamente.

Una vez que las cosas funcionan, puede ejecutar dnsmasqsin las opciones --no-daemony --log-queries, por lo que comenzará en segundo plano y no necesitará mantener abierta una ventana de Terminal.

Noté que tenía 10.94.62.3 en la lista de servidores DNS (panel de preferencias de red) seguido de 2 de mi ISP. Eliminé los otros 2, forzando todas las búsquedas de nombres a través de 10.94.62.3 para esta ubicación y ahora puedo resolver nombres en mi red, así como en el exterior.

No tengo idea de por qué esto funcionó.

Supongo que tenemos un problema similar, como lo describí aquí: /apple/50457/nslookup-works-ping-and-ssh-dont-os-x-lion-10-7-3

Creo que el problema radica en la configuración de los dominios de búsqueda: ping / ssh intenta usar el gethostbyname2()cual falla porque named ya no se está ejecutando (al menos en Lion) y, por lo tanto, /etc/resolv.confcon los dominios de búsqueda configurados se ignora. /etc/hostses el último recurso para gethostbyname2()y, por lo tanto, ssh funciona de nuevo con las entradas adecuadas en /etc/hosts. Debería ser reparado por Apple imho.

¿Has probado nevada-example-com.local?

dscacheutil -flushcache

Ese comando actualiza su caché DNS.

¿Es 10.94.62.3 un servidor DNS en el que confía? Si es así, ¿por qué solo hay uno? Debe tener al menos 2 servidores DNS a los que hacer referencia para fines de conmutación por error. Si ese cae, eres un pato sentado.

Las búsquedas de pedidos de DNS parecen funcionar de manera diferente en Snow Leopard. Si no puede buscar un dominio, verifique si tiene algún servidor DNS no válido en sus preferencias de red. Si está utilizando una configuración DHCP estándar, no debería tener ningún Servidor DNS en la lista. Antes de mi actualización, tenía un antiguo servidor DNS en la lista, y no afectó nada. Una vez que actualicé, perdí totalmente el dns.

Abra Preferencias de red> Elegir aeropuerto> Avanzado. Seleccione la pestaña DNS y elimine los servidores DNS que no sean válidos.

¿Has mirado en la consola? (Aplicaciones -> Utilidades -> Consola) Es posible que mDNSResponder aparezca en: Información de diagnóstico y uso -> Informes de diagnóstico del sistema

Si se bloquea debido a otro programa que está cargando módulos (como Little Snitch o Hands Off), puede verlo allí.

Tuve el mismo problema con nslookup resolviendo mi ventana de Windows, pero ping me dio un "host desconocido". Intenté lo que sugirió Navdeep y fui a borrar los servidores de nombres en la pestaña Preferencias de red-> Avanzado-> DNS. No me dejaba restarlos, estaban en gris. Finalmente llegué al + y desaparecieron. Cancelé agregar uno nuevo y apliqué cambios, una vez que no se mostraban servidores DNS. Ping comenzó a trabajar después de eso. Lo extraño es que mi enrutador local / servidor DHCP fue el primero en la lista y es el responsable de resolver el cuadro de Windows. Debe ser algo extraño con el pedido. El otro servidor de nombres listado es un NS de trabajo y no podría resolver el host de Windows. GRACIAS Navdeep!