DNS no se resuelve en Mac OS X

Algunos de mis compañeros de trabajo tienen problemas con sus Macs: la resolución DNS no funciona en Mac OS X. Están ejecutando Snow Leopard 10.6.8. Pueden usar DNS en una máquina virtual con Windows 7 (VMware Fusion 3.1.3) que se ejecuta en OS X. Las computadoras son MacBook Pros de 15 ", modelo de principios de 2011.

Cosas que han intentado que no han funcionado:

• encender / apagar el aeropuerto
• reinicio
• usando conexión por cable en lugar de wifi
• eliminar credenciales de conexión y agregarlo nuevamente
• desactivar el firewall de Mac
• utilizando IP estática fija
• Configuración manual de servidores DNS
• reiniciar mDNSResponder
• las soluciones de esta otra pregunta

EDITAR respuesta Respuesta de Martín:

• ¿Puedes hacer ping al DNS que quieres usar?

$ ping apple.com
ping: cannot resolve apple.com: Unknown host

• ¿Cuál es / son las direcciones IP de los DNS que desea usar?

Este es un servidor DNS de la empresa que se proporciona con DHCP, funciona bien para otras personas. También probé los 8.8.4.4 y 205.171.3.65 de Google (que encontré en el DNS Benchmark de GRC como el más rápido).

• ¿Has probado usar 8.8.8.8 (google) o alguno de los OpenDNS 208.67.222.222 o 208.67.220.220?

No funciona, vea la salida de Google Chrome:

No se puede encontrar el servidor en www.apple.com porque la búsqueda de DNS falló. DNS es el servicio de red que traduce el nombre de un sitio web a su dirección de Internet. Este error suele deberse a que no tiene conexión a Internet o una red mal configurada. También puede ser causado por un servidor DNS que no responde o un firewall que impide que Google Chrome acceda a la red.

• ¿Puedes hacer ping a esos hosts?

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from
8.8.8.8: icmp_seq=0 ttl=58 time=3.925 ms

• crear un usuario en blanco

Se creó una cuenta de usuario invitado, el problema de DNS todavía estaba presente cuando se usaba la cuenta de invitado.

• nslookup y cavar ambos funcionan bien

$ nslookup www.apple.com 8.8.8.8
Server:  8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
www.apple.com canonical name = www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net canonical name = e3191.c.akamaiedge.net.
Name: e3191.c.akamaiedge.net
Address: 184.24.141.15

$ dig @8.8.8.8 www.apple.com
; <<>> DiG 9.6.0-APPLE-P2 <<>> @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11298
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;www.apple.com.   IN A
;; ANSWER SECTION:
www.apple.com.  1041 IN CNAME www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 38 IN CNAME www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 8794 IN CNAME e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 17 IN A 184.24.141.15
;; Query time: 4 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Oct 4 09:25:28 2011
;; MSG SIZE  rcvd: 158

• también se limpió el caché de DNS pero no ayudó

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

EDITAR 2 :

$ cat /etc/resolv.conf
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
domain {redacted}.com
nameserver 8.8.8.8
nameserver 208.67.222.222

Resulta que la solución fue rebotar mDNSResponder:

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

Esto fue obtenido por un compañero de trabajo diferente de esta pregunta de Falla del servidor .

OS X 10.10.0 - 10.10.3, Yosemite

Aparentemente , mDNSResponder no existe en Yosemite (OS X 10.10). Puede reiniciar descoveryd en su lugar para solucionar estos problemas.

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

OS X 10.10.4+, Yosemite

En OSX 10.10.4 el mDNSResponder ha sido reintroducido . Así que use el primero funcionará nuevamente.

En realidad, creo que quizás quieras usar

scutil --dns

scutil -r hostname

Estos comandos usan el almacenamiento dinámico en configd, a diferencia de los archivos planos en / etc, que a menudo solo se leen en modo de usuario único y para sistemas no conectados en red.

man scutil   # or

scutil --help  

La resolución de nombres bajo OSX (y UNIX en general) se toma de las direcciones IP de los DNS en el archivo ubicado en /etc/resolv.conf (que OS X genera automáticamente hasta donde puedo recordar).

Como has intentado prácticamente cualquier cosa que se me ocurra, me gustaría preguntarte:

• ¿Puedes hacer ping al DNS que quieres usar?
• ¿Cuál es / son las direcciones IP de los DNS que desea usar?
• ¿Has probado usar 8.8.8.8 (google) o alguno de los OpenDNS 208.67.222.222 o 208.67.220.220?
• ¿Puedes hacer ping a esos hosts?

Finalmente, una prueba generalmente buena consiste en crear un usuario en blanco y ver si ese nuevo usuario presenta el mismo problema. Si no es así, puede comenzar a cavar lo que tiene su usuario actual que podría estar causando el problema; si también falla, entonces sabes que esto es algo más relacionado con el "sistema".

También eche un vistazo a la consola para ver si puede detectar algo que pueda estar relacionado (y le gustaría pegar por aquí).

Por último, pero no menos importante, tu Mac viene con dos comandos DNS importantes, nslookupy dig.

Entonces, para resolver www.apple.com usando el servidor de Google, escriba:

nslookup "host para resolver" "servidor DNS para usar". P.ej:

$ nslookup www.apple.com 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
www.apple.com   canonical name = www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net    canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net   canonical name = e3191.c.akamaiedge.net.
Name:   e3191.c.akamaiedge.net
Address: 184.24.141.15

NSLookup es un comando antiguo (que se suponía que estaba en desuso hace unos años y reemplazado por DIG, pero supongo que su sintaxis fácil de usar era demasiado buena para matar), su "reemplazo" es digun comando mucho más poderoso, cuya sintaxis Es más loco.

Para realizar la misma consulta, escribiría:

dig @ 8.8.8.8 www.apple.com

Y aquí está el resultado:

$ dig @8.8.8.8 www.apple.com

; <<>> DiG 9.7.3 <<>> @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17356
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.apple.com.         IN  A

;; ANSWER SECTION:
www.apple.com.      1782    IN  CNAME   www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 42 IN CNAME   www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 21581 IN CNAME   e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 2   IN  A   184.24.141.15

;; Query time: 26 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Oct  3 21:21:49 2011
;; MSG SIZE  rcvd: 158

Como puede ver, cavar es mucho más "detallado" (lo cual es bueno para depurar lo que está pasando). El poder de la excavación proviene del hecho de que puede especificar qué tipo de consulta desea realizar (entre otras cosas).

En cualquier caso, háganos saber los resultados exactos de estos comandos.

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
  user=nobody
  group=nobody
  interface=lo0
  cache-size=1024
  

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

  nameserver 8.8.8.8
  nameserver 4.2.2.1
  nameserver 4.2.2.2
  

• Corre dnsmasqcon sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf. La salida debería verse algo así como:

  ...
  dnsmasq: reading resolv.conf
  dnsmasq: using nameserver 4.2.2.1#53
  dnsmasq: using nameserver 4.2.2.2#53
  dnsmasq: using nameserver 8.8.8.8#53
  dnsmasq: read /etc/hosts - 6 addresses
  

• 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 necesita mantener abierta una ventana de Terminal.

Tuve exactamente los mismos síntomas (y pasé un tiempo resolviendo problemas) pero pude resolverlo cuando me di cuenta de que me metí /System/Library/LaunchDaemons/com.apple.mDNSResponder.plisty lo que hice fue interpretado de alguna manera como malformado. Restablecí desde una copia de seguridad y la máquina pudo resolver los nombres de host nuevamente.

Antes de llegar a la solución, también me di cuenta de que podía navegar en Internet si usaba un proxy SOCKS5 ssh -De intentaba buscar DNS a través del túnel.

Tuve un problema muy, muy similar, excepto que los síntomas fueron ligeramente diferentes.

Mi usuario no pudo resolver ningún nombre (NAS local, Google, etc.) pero un usuario invitado en el mismo iMac (OS X 10.7.4) funcionó bien.

Vaciar y reiniciar mDNSResponder como se mencionó funcionó por un tiempo. Si bien seguiría funcionando cuando el iMac se pusiera en modo de suspensión, siempre fallará una vez que se reinicie.

Cuando el vaciado / reinicio dejó de funcionar, busqué otras razones / soluciones y descubrí que estaba relacionado con mi firewall. No sé qué estaba causando en mi configuración de firewall (OS X), pero si restauré la configuración del firewall funcionó.

Para restaurar la configuración predeterminada que utilicé:

sudo cp /usr/libexec/ApplicationFirewall/com.apple.alf.plist /Library/Preferences/com.apple.alf.plist

Obviamente, cualquier regla personalizada se habrá eliminado con esta restauración.

Quería compartir mi versión de este problema, ya que me ha estado causando dolor durante meses y esta publicación es la mejor colección de soluciones posibles en la red.

Llegué a este problema en Yosemite (10.10). Resulta que un demonio clave discoverydfue eliminado, ya que consumía demasiada CPU.

2014/10/22 3:50:07.000 PM kernel[0]: process discoveryd[49] thread 1251 caught burning CPU! It used more than 50% CPU (Actual recent usage: 68%) over 180 seconds. thread lifetime cpu usage 90.016372 seconds, (74.516637 user, 15.499735 system) ledger info: balance: 90007570271 credit: 90007570271 debit: 0 limit: 90000000000 (50%) period: 180000000000 time since last refill (ns): 131905306167 

Extrañamente reiniciar no hizo que se reiniciara.

Reinicié manualmente el servicio con:

sudo launchctl kickstart -k system/com.apple.networking.discoveryd

Y ahora todo está bien.

Tengo el mismo problema con 10.6.8. El primer viaje a una Apple Store resultó en la restauración del sistema. Pero, después de eso, el DNS se rompió nuevamente mientras estaba en el extranjero y no tenía un DVD del sistema conmigo. En ese momento encontré este hilo y lo /System/Library/LaunchDaemons/com.apple.mDNSResponder.plisteliminé por @freezedpeanuts y @Tom Thorogood.

Solucionó el problema, pero, sorprendentemente, el DNS se rompió por tercera vez un par de días después. Busqué una imagen del sistema de 10.6.3 y:

1. Copiado /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistde la imagen del sistema.
2. sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
3. Reiniciado

Eso solucionó el problema.

Se rompe periódicamente para mí ahora (una vez al mes más o menos), y el procedimiento de restauración sigue los pasos anteriores, excepto que en lugar de reiniciar puede:

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

Tenga en cuenta que si aún tiene problemas, es posible que deba eliminar los servidores DNS públicos hasta que se borre la memoria caché.

Aparentemente tuve el mismo problema que el OP. Usando la herramienta networksetup, descubrí que para el nombre de red dado, se configuró un DNS incorrecto:

networksetup -getdnsservers <networkname>

enumeró 192.168.0.1 como DNS. Usando scutil --dns obtuve resultados comparables, enumerando que el resolutor # 2 usó el servidor de nombres [0]: 192.168.0.1.

Usando el comando

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

Pude reconfigurar el DNS para la red dada y resolver nombres de máquinas locales y globales cuando estaba conectado a la VPN.

En mi caso, todo lo demás estaba bien: mDNSResponder estaba funcionando y funcionando, host/ nslookupfuncionó, ambos /etc/resolv.confy networksetupreportaron los servidores DNS correctos, etc. A pesar de todo eso, la resolución DNS en general (por ejemplo, con ping) inevitablemente dejó de funcionar en algún momento unas horas después bota.

Este problema específico puede ser algo improbable, pero de todos modos lo documentaré aquí como respuesta.

Solo noté cuando la máquina comenzó a disminuir la velocidad, pero había muchos procesos idénticos ejecutándose . sensu-clientespecíficamente.

Lo configuramos en launchd con este archivo plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd>
<plist version="1.0">
  <dict>
  <key>KeepAlive</key>
  <true/>
  <key>RunAtLoad</key>
  <true/>
  <key>WorkingDirectory</key>
  <string>/etc/sensu</string>
  <key>UserName</key>
  <string>root</string>
  <key>Label</key><string>org.sensuapp.sensu-client</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/bin/sensu-client</string>
      <string>-d/etc/sensu/conf.d/</string>
      <string>-b</string>
    </array>
  </dict>
</plist>

La -bbandera sensu-clienthace que se bifurque hacia el fondo, actuando como un demonio. Sin embargo, todo launchdlo que se ve es que el proceso original terminó, por lo que (de acuerdo con el KeepAliveindicador) lo reinicia. Esto deja miles de procesos bifurcados en segundo plano, e incluso entonces launchd no será más sabio al hecho de que se está ejecutando.

Creo que estos varios miles de procesos (todos sensu-client, el software para el que habíamos escrito una configuración de launchd) pueden haber estado haciendo solicitudes simultáneamente a mDNSResponder, resultando efectivamente en una denegación local de servicio de la caché DNS . Matar estos procesos y arreglar el plist dado a launchd eventualmente resolvió el problema.

La solución de plist fue simplemente eliminar el -bindicador (background / daemonise) de la invocación sensu-client. Tenga en cuenta que esto no es culpa de sensu; Este plist fue escrito por un antiguo administrador del sistema de esta empresa.

Aquí hay algunos comandos avanzados que pueden ayudar a solucionar el problema de DNS:

• Ejecute digpara enumerar los servidores de nombres raíz.
• Ejecutar dig example.compara ejecutar la búsqueda de DNS para el example.comdominio.
• Una lista de sus puertos de hardware por: networksetup -listallhardwareports.
• Compruebe la salida del paquete DHCP / BOOTP que el cliente acepta desde el servidor DHCP / BOOTP por: ipconfig getpacket en0.
• Compruebe la configuración de DNS por: scutil --dns.
• Verificar que mDNSResponderel proceso se está ejecutando por: ps wuax | grep mDNSResponder.
• Enjuague las entradas de traducción ARP por: arp -ad(solicite man arpayuda). ^fuente

Para depurar el mDNSResponderproceso, el siguiente comando puede ayudar:

(sleep 1 && sudo killall -INFO mDNSResponder &); log stream | grep mDNSResponder

El comando anterior enviará una SIGINFOseñal al proceso que volcará los detalles de depuración en la salida del registro que se puede leer y analizar.

Apagar y volver a encender el Wi-Fi ayudó.

^{MacBook Pro con 10.9.1}

Especialmente si apaga el wifi y luego reinicia. La demora adicional y el inicio sin conexión IP / red aseguran que la solicitud para volver a unirse a la red tenga mejores posibilidades de tener éxito.

Esto probablemente no ayudará a nadie, pero en caso de que accidentalmente hace algún tiempo creé un archivo en la carpeta, cuando un DNS estaba inactivo para un dominio en particular:

/ etc / resolver /

y esto impedía que un nombre específico se resolviera, dos años después.

Desafortunadamente, nada de esto me ayudó, y resultó después de una hora de tratar de resolverlo y golpear mi cabeza contra la mesa de café ... algo, de alguna manera, en algún lugar ... eliminó el /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistarchivo, y fue la razón por la que tuve este problema.

Me di cuenta de esto cuando vi este mensaje de error: /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist: No such file or directory

Aquí hay una copia de una versión de El Capitan: https://gist.github.com/tripflex/e7147690d1768dc74b1dd626614573c0

Aquí está el código de esa esencia:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.apple.mDNSResponder.reloaded</string>
    <key>OnDemand</key>
    <false/>
    <key>InitGroups</key>
    <false/>
    <key>UserName</key>
    <string>_mdnsresponder</string>
    <key>GroupName</key>
    <string>_mdnsresponder</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/sbin/mDNSResponder</string>
    </array>
    <key>MachServices</key>
    <dict>
        <key>com.apple.mDNSResponder</key>
        <true/>
            <key>com.apple.mDNSResponder.dnsproxy</key>
            <true/>
    </dict>
    <key>Sockets</key>
    <dict>
        <key>Listeners</key>
        <dict>
            <key>SockFamily</key>
            <string>Unix</string>
            <key>SockPathName</key>
            <string>/var/run/mDNSResponder</string>
            <key>SockPathMode</key>
            <integer>438</integer>
        </dict>
    </dict>
    <key>POSIXSpawnType</key>
    <string>Interactive</string>
    <key>EnablePressuredExit</key>
    <false/>
</dict>
</plist>

Resulta que, para resolver el problema, debe configurar un dominio de búsqueda y agregarlo al campo de dominio de búsqueda en Configuración DNS de Preferencias del Sistema. Básicamente, el dominio de búsqueda funcionará de la manera que lo hace .local, pero en cambio lo será.

Debe configurar su dominio de búsqueda como zona maestra en su servidor dns para que esto funcione.

Tengo un problema similar con la búsqueda del servidor host. Tenemos 21 iMacs ejecutándose desde el servidor (El Capitan, actualizado recientemente) y solo uno no se vinculará. La solución suele ser bastante simple a través de Usuarios y Grupos en SysPref. Eliminar el servidor host y volver a vincular, encontrar el servidor disponible en la opción desplegable, pero por alguna razón desconocida el servidor aparece en la lista unkown-00-00-12-34-56-78.home, que he encontrado es la dirección MAC del servidor. Ejecuté esto en la terminal:

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

y

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

¡volví a enlazar al servidor en SysPref y la opción correcta del nombre del servidor apareció brevemente y luego cambió de nuevo a "unkown-00-00-12-34-56-78.home" justo en frente de mis ojos!

Al seguir los comandos de la respuesta aceptada:

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

puede toparse con una advertencia:

Operación no permitida mientras la Protección de integridad del sistema está activada

Necesitas apagarlo. Toda la instrucción aquí: https://www.howtogeek.com/230424/how-to-disable-system-integrity-protection-on-a-mac-and-why-you-shouldnt/

En mi caso, tenía OpenDNS instalado en el pasado y no se eliminó limpiamente. Hubo varios procesos relacionados con dns en ejecución, como DNSdnscrypt-proxy. No pude forzar el cierre en Activity Monitor, pero pude evitar que se iniciaran al reiniciar eliminando el archivo .plist en Library / LaunchDaemons.

Vaya a Configuración -> Red -> Avanzado -> DNS. Luego, haga literalmente cualquier cambio en DNS (reordene sus entradas DNS, por ejemplo). Luego haga clic en "Aceptar" seguido de "Aplicar" en la siguiente pantalla. No se deje engañar pensando que el cambio particular que hizo fue significativo; Es la magia del botón "Aplicar".

~ $  time nslookup www.google.com
;; connection timed out; no servers could be reached


real    0m21.041s
user    0m0.006s
sys     0m0.010s

 ~ $  time nslookup www.google.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   www.google.com
Address: 172.217.5.4


real    0m0.079s
user    0m0.006s
sys     0m0.010s

Lo que funcionó para mí fue eliminar todas las entradas del servidor de los servidores DNS y los dominios de búsqueda de:

Preferencias del sistema → Red → Avanzado ... → DNS

Después de actualizar de Snow Leopard en un viejo Mac Book a Mountain Lion, el sistema no pudo resolver DNS. Enrojecimiento, reinicio, nada ayudó. Cambiar WiFi a un punto de acceso diferente (mi teléfono) ayudó.

Mountain Lion agrega un nuevo campo de cliente a la configuración de red DHCP. Llenar este campo parecía hacer feliz el punto de acceso wifi. Dejarlo en blanco significaba que no pasaba nada, a pesar de que la conexión wifi parecía tener éxito.