DNS no se está resolviendo en Mac OS X

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 fallo 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, mDNSResponder ha sido reintroducido . Por lo tanto, usar el primero funcionará de nuevo.

En realidad, creo que es posible que desee utilizar

scutil --dns

scutil -r hostname

Estos comandos utilizan el almacén 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  

He experimentado el mismo problema ... Y al reiniciar mDNSResponder parece que "funciona", reiniciarlo un par de veces cada hora como que apesta.

Por ahora, "solucioné" el problema ejecutando dnsmasq localmente. Para hacer eso:

• Genere dnsmasq (descargue el tgz y make o brew install dnsmasq )

• Coloca esto en un archivo dnsmasq.conf :

  resolv-file=resolv.conf
  user=nobody
  group=nobody
  interface=lo0
  cache-size=1024
  

• Coloca esto en un archivo resolv.conf que esté en el mismo directorio que el archivo dnsmasq.conf (nb: no /etc/resolv.conf ):

  nameserver 8.8.8.8
  nameserver 4.2.2.1
  nameserver 4.2.2.2
  

• Ejecuta dnsmasq con sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf . La salida debería verse algo 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.1 sea el único servidor DNS (preferencias de red - > advanced - > DNS - > add 127.0.0.1)

Las cosas deberían comenzar a funcionar bien otra vez.

Una vez que las cosas estén funcionando, puede ejecutar dnsmasq sin las opciones --no-daemon y --log-queries , por lo que se iniciará en segundo plano y no necesita mantener abierta la ventana de Terminal.

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

Ya que has intentado virtualmente cualquier cosa que me venga a la mente, 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?
• ¿Ha intentado 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 agradable consiste en crear un usuario en blanco y ver si ese nuevo usuario presenta el mismo problema. Si no lo hace, entonces puede comenzar a investigar qué 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 que desee pegar aquí).

Por último, pero no menos importante, tu Mac incluye dos comandos DNS importantes, nslookup y dig .

Para resolver www.apple.com utilizando el servidor de google, escriba:

nslookup "host para resolver" "servidor DNS para usar". Por ejemplo:

$ 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 algunos años y reemplazado por DIG, pero supongo que su sintaxis fácil de usar era demasiado buena para matar), su "reemplazo" es dig , mucho Comando más poderoso, cuya sintaxis es más loca.

Para realizar la misma consulta, escribirías:

dig @ 8.8.8.8 www.apple.com

Y aquí está la salida:

$ 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 puedes ver, cavar es mucho más "detallado" (lo que es bueno para depurar qué diablos 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.

Tuve los mismos síntomas exactos (y pasé un tiempo resolviendo problemas) pero pude resolverlo cuando me di cuenta de que me metí con /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist y lo que hice se interpretó de alguna manera como malformado. Lo restauré 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 por Internet si usaba un proxy SOCKS5 a través de ssh -D y probaba búsquedas de 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.

El lavado y reinicio de mDNSResponder como se mencionó funcionó por un tiempo. Aunque seguirá funcionando cuando el iMac se puso en modo de suspensión, siempre fallará una vez que se reinicie.

Cuando el lavado / reinicio dejó de funcionar, busqué otras razones / soluciones y encontré que estaba relacionado con mi firewall. No sé what en la configuración de mi firewall (OS X) lo estaba causando, 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, con esta restauración se eliminarán todas las reglas personalizadas.

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!

Encontré este problema en Yosemite (10.10). Resulta que un daemon clave, discoveryd , fue 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 

El reinicio extraño no hizo que se reiniciara.

Reinicié manualmente el servicio con:

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

y ahora todo está bien.

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

Se 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.plist de la imagen del sistema.
2. sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
3. reiniciado

Eso solucionó el problema.

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

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

Tenga en cuenta que cualquier persona que aún tenga problemas, es posible que deba eliminar cualquier servidor DNS público hasta que se borre la memoria caché.

Aparentemente tuve el mismo problema que el OP. Usando la herramienta networksetup, encontré que para el nombre de red dado, se configuró algún DNS incorrecto:

networksetup -getdnsservers <networkname>

listó 192.168.0.1 como DNS. Usando scutil --dns obtengo resultados comparables, listando que el resolutor # 2 usó nameserver [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 los nombres de las máquinas locales y globales cuando estoy conectado a la VPN.

La activación y desactivación de la conexión Wi-Fi volvió a funcionar.

^{MacBook Pro con 10.9.1}

Especialmente si apagas wifi y luego reinicias. El retraso adicional y el inicio sin conexión IP / de red aseguran que la solicitud de reincorporarse a la red tenga mejores posibilidades de éxito.

En mi caso, todo lo demás estaba bien: mDNSResponder funcionaba y funcionaba, host / nslookup funcionaba, tanto /etc/resolv.conf como networksetup reportaron los servidores DNS correctos, etc. A pesar de todo eso, la resolución de DNS en general (por ejemplo, con ping ) inevitablemente dejó de funcionar en algún momento unas horas después del inicio.

Este problema específico puede ser un poco improbable, pero voy a documentarlo aquí como una respuesta de todos modos.

Solo noté cuando la máquina comenzó a desacelerarse, pero había muchos procesos idénticos en ejecución . sensu-client , específicamente.

Lo teníamos configurado 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 bandera -b to sensu-client hace que se bifurque al fondo, actuando como un demonio. Sin embargo, todo lo que launchd ve es que el proceso original terminó, por lo que (de acuerdo con el indicador KeepAlive ) lo reinicia. Esto deja miles de procesos bifurcados en segundo plano, e incluso entonces launchd no será más consciente del 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 launchd) pueden haber realizado simultáneamente solicitudes a mDNSResponder, lo que efectivamente resultó en un local denegación de servicio de la caché de DNS . Matar estos procesos y arreglar el error dado para el lanzamiento y eventualmente resolvió el problema.

La corrección de errores fue solo para eliminar el indicador -b (background / daemonise) de la invocación sensu-client. Tenga en cuenta que esto no es culpa de sensu; esta lista fue escrita por un antiguo administrador del sistema en esta compañía.

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

• Ejecute dig para enumerar los servidores de nombres raíz.
• Ejecute dig example.com para ejecutar la búsqueda de DNS para example.com dominio.
• Liste sus puertos de hardware por: networksetup -listallhardwareports .
• Verifique la salida del paquete DHCP / BOOTP que el cliente aceptó del servidor DHCP / BOOTP mediante: ipconfig getpacket en0 .
• Verifique la configuración de su DNS mediante: scutil --dns .
• Verifique que el proceso mDNSResponder se esté ejecutando mediante: ps wuax | grep mDNSResponder .
• Vacíe las entradas de traducción de ARP mediante: arp -ad (ejecute man arp para obtener ayuda). ^fuente

Para depurar el proceso mDNSResponder , el siguiente comando puede ayudar:

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

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

Resulta que, para resolver el problema, debe configurar un dominio de búsqueda y agregarlo al campo de dominio de búsqueda en la configuración de preferencias del sistema dns. Básicamente, el dominio de búsqueda funcionará de la forma en que lo hace .local, pero en cambio lo será.

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

Tengo un problema similar con la búsqueda del servidor host. Tenemos 21 iMacs que se ejecutan desde el servidor (El Capitán, actualizado recientemente) y solo uno no se puede vincular. La solución suele ser bastante simple a través de Usuarios y Grupos en SysPref. Eliminar el servidor host y volver a vincularlo, encontrar el servidor disponible en la opción desplegable, pero por alguna razón desconocida, el servidor aparece como unkown-00-00-12-34-56-78.home , que he encontrado es la dirección MAC del servidor. Corrí 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

regresó para enlazar al servidor en SysPref y apareció brevemente la opción de nombre de servidor correcta y luego volvió a cambiar a "unkown-00-00-12-34-56-78.home" ¡justo frente a mis ojos!

Es probable que esto no ayude 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ó que después de una hora de intentarlo y golpear mi cabeza contra la mesa de café ... algo, de alguna manera, en algún lugar ... eliminó el archivo /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist , y fue razón por la que tuve este problema.

Se dio 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 Capitán: enlace

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>

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 aparecer en advertencia:

  

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

Necesitas apagarlo. Toda la instrucción aquí: enlace

Después de actualizar Snow Leopard en un viejo Mac Book a Mountain Lion, el sistema no pudo resolver el DNS. Enrojecer, reiniciar, nada ayudó. El cambio de 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 de DHCP. Rellenar este campo parece hacer feliz al punto de acceso wifi. Dejarlo en blanco significaba que no se estaba haciendo nada, a pesar de que la conexión wifi parecía tener éxito.