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

14

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

domain-name-system ssh mac-osx

— Peter Cardona
fuente

¿Se puede enviar a (a) nevada.example.com y (b) 10.94.62.3?

— Sven

2

¿Puedes hacer ping a Nevada? ¿Qué muestra "ssh -v nevada"?

— markdrayton

Extraña pregunta; ¿Usas Split DNS y / o puedes hacer ping a nevada?

— Chealion

Gracias por los seguimientos ... respuestas: ssh nevada.example.com = no ssh 10.94.62.3 = sí (y tuve que confirmar la clave del host porque había borrado los hosts conocidos) ping nevada = problema de resolución de nombres telnet nevada (aunque no funciona telnetd) = problema de resolución de nombre Dividir DNS = no intencionalmente, no sé qué es :-) Desde el panel de configuración de red OS X, tengo 10.94.62.3 como el servidor DNS enumerado antes de los dos proporcionados por mi ISP y example.com en la lista de dominios de búsqueda. Otros sistemas en mi red pueden usar DNS normalmente para ssh a nevada (y otros).

— Peter Cardona

lo siento por la falta de saltos de línea en el comentario anterior ...

— Pedro Cardona

16

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.

— Chealion
fuente

Gracias, googlear me llevó aquí, esto lo arregló. "arp" informó la IP incorrecta, dig informó la "ip" correcta. Ninguna cantidad de dns flushing lo arregló antes de intentar esto. Observo que también tuve que ejecutar dscacheutil -flushcache. También quisiera señalar que los enrutadores locales pueden comportarse de manera extraña y los ISP a veces no son justos en términos de TTL.

— Aitch

9

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.

— Steve Harris
fuente

wow eso funcionó !!! ¡He estado buscando una solución en todas partes! Estaba a punto de formatear y restaurar mi computadora portátil, ¡me ahorró un montón de tiempo! ¡Gracias! lo siento, pero no pude votar :-( Nota: mi DNS dejó de funcionar después de ejecutar Util OnyX, no sé por qué. Pude usar dig / nslookup pero nada más.

2

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.

— David Wolever
fuente

1

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

— Peter Cardona
fuente

1

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.

— tholu
fuente

0

¿Has probado nevada-example-com.local?

— Jeremy L
fuente

No lo había intentado, pero obtuve el mismo problema de resolución. Comienza a parecer que NADA (ssh, telnet, ping, http) se resuelve a través del servidor en el que nslookup está predeterminado. ¿Cómo es posible? ¿Tal vez un conflicto entre la configuración de nivel de OS X y algún / etc / cualquier archivo que le interese a la implementación BSD subyacente?

— Peter Cardona el

No, OS X no utiliza niveles de inicio, ni siquiera el subsistema BSD.

— Jeremy L

0

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.

— churnd
fuente

0

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.

0

¿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í.

— jwilkins
fuente

-1

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!

— Chris
fuente