DNS no se resuelve 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 falla del servidor .

OS X 10.10.0 – 10.10.3, Yosemite

Aparentemente , mDNSResponder no existe en Yosemite (OS X 10.10). En su lugar, puede reiniciar descubrimiento 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, se reintrodujo mDNSResponder . Así que usa el primero que funcionará de nuevo.

De hecho, creo que podrías querer 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 que no están en red.

man scutil   # or

scutil --help  

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

Entonces, por ahora, "resolví" el problema ejecutando dnsmasq localmente. Para hacer eso:

• Compile 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: no /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 ser 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.1sea el único servidor DNS (preferencias de red -> avanzado -> DNS -> agregue 127.0.0.1)

Las cosas deberían empezar a funcionar bien de nuevo.

Una vez que las cosas funcionan, puede ejecutar dnsmasqsin las opciones --no-daemony --log-queries, por lo que se iniciará en segundo plano y no necesita mantener abierta una 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 probado prácticamente todo lo que se me ocurre, me gustaría preguntarte:

• ¿Puedes hacer ping al DNS que quieres usar?
• ¿Cuáles son las direcciones IP de los DNS que desea utilizar?
• ¿Ha intentado usar 8.8.8.8 (google) o cualquiera de los OpenDNS 208.67.222.222 o 208.67.220.220?
• ¿Puedes hacer ping a esos hosts?

Finalmente, una buena prueba generalmente consiste en crear un usuario en blanco y ver si ese nuevo usuario presenta el mismo problema. Si no es así, 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 encontrar algo que pueda estar relacionado (y le gustaría pegarlo aquí).

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

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

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 sería obsoleto 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 digun comando mucho más poderoso, cuya sintaxis es más loco.

Para realizar la misma consulta, escribiría:

cavar @ 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 puede ver, dig es mucho más "detallado" (lo cual es bueno para depurar qué diablos está pasando). El poder de dig proviene del hecho de que puede especificar qué tipo de consulta desea realizar (entre otras cosas).

En cualquier caso, háganos saber las salidas exactas de estos comandos.

Tuve exactamente los mismos síntomas (y pasé un tiempo resolviendo el problema), pero pude resolverlo cuando me di cuenta de que me metí /System/Library/LaunchDaemons/com.apple.mDNSResponder.plisty lo que hice se interpretó de alguna manera como incorrecto. 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 ssh -Dy probaba las búsquedas de DNS a través del túnel.

Tuve un problema muy, muy similar, excepto que los síntomas eran 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 seguía funcionando cuando el iMac se ponía en modo de suspensión, siempre fallaba una vez que se reiniciaba.

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

Para restaurar la configuración predeterminada que usé:

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

Obviamente, todas las reglas personalizadas se habrán eliminado con esta restauración.

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

Me encontré con este problema en Yosemite (10.10). Resulta que un demonio clave, discoveryd, fue eliminado porque 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 volvió a fallar mientras estaba en el extranjero y no tenía conmigo un DVD del sistema. En ese momento encontré este hilo y /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistlo eliminé 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 se reduce a 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 todavía tiene problemas, es posible que deba eliminar cualquier servidor DNS público hasta que se borre el caché.

Aparentemente tuve el mismo problema que el OP. Usando la herramienta networksetup, encontré 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 servidor de resolución # 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.

Apagar y volver a encender Wi-Fi ayudó.

^{MacBook Pro con 10.9.1}

Especialmente si apagas wifi y luego reinicias. El retraso adicional y el inicio sin IP/conexión de red aseguran que la solicitud para volver a unirse a la red tenga mejores posibilidades de é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 se resolviera un nombre específico, dos años después.

En mi caso, todo lo demás estuvo bien: mDNSResponder se estaba ejecutando y funcionando, host/ nslookupfuncionó, ambos /etc/resolv.confe networksetupinformaron 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 bota.

Este problema específico puede ser poco probable, pero lo documentaré aquí como una respuesta de todos modos.

Solo noté cuando la máquina comenzó a ralentizarse, pero había muchos procesos idénticos ejecutándose . 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 -bbandera sensu-clienthace que se bifurque hacia el fondo, actuando como un demonio. Sin embargo, todo launchdlo que ve es que el proceso original terminó, por lo que (de acuerdo con la KeepAlivebandera) lo reinicia. Esto deja miles de procesos bifurcados en segundo plano, e incluso entonces launchd no se dará cuenta 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 de inicio) pueden haber estado realizando solicitudes simultáneamente a mDNSResponder, lo que resultó en una denegación de servicio local del caché DNS . Matar estos procesos y arreglar el plist dado a launchd finalmente resolvió el problema.

La corrección de plist fue simplemente eliminar el -bindicador (fondo / daemonise) de la invocación de sensu-client. Tenga en cuenta que esto no es culpa de sensu; este plist fue escrito por un ex administrador de sistemas de esta empresa.

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

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

Para depurar mDNSResponderel proceso, el siguiente comando puede ayudar:

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

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

Desafortunadamente, nada de esto me ayudó, y resultó después de una hora de tratar de resolverlo y golpearme la 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>

Reiniciar DNSResponder/borrar caché de DNS en macOS Mojave:

sudo killall -HUP mDNSResponder

No hay problemas con System Integrity Protection, a diferencia de volver a cargar los archivos de configuración.

En mi caso, la causa raíz fue que el sistema de protección DoS de mi enrutador WiFi doméstico agregó por error la dirección MAC de mi dispositivo macOS a la lista negra. Después de borrar manualmente la lista negra y ejecutar los sudo killall -HUP mDNSRespondercomandos dig, ping y traceroute funcionan bien.

En Mac OS Mojave 10.14.6, recientemente comencé a ver fallas frecuentes en la búsqueda de dns. Tengo esta función en mi .bashrc:

function resetdns() {
     dscacheutil -flushcache;
     sudo killall -HUP mDNSResponder
     sudo killall -9 mDNSResponder mDNSResponderHelper
     sudo launchctl stop homebrew.mxcl.dnsmasq 
     sudo launchctl start homebrew.mxcl.dnsmasq
}

en funcionamiento

$ resetdns

Las búsquedas de dns comenzaron a funcionar bien nuevamente.

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 dns de Preferencias del sistema. Básicamente, el dominio de búsqueda funcionará de la misma manera que lo hace .local, pero en su lugar será .

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

Tengo un problema similar al encontrar el servidor host. Tenemos 21 iMacs ejecutándose desde el servidor (El Capitan, actualizado recientemente) y solo uno no se enlaza. La solución suele ser bastante simple a través de Usuarios y Grupos en SysPref. Eliminando el servidor host y volviendo a enlazar, encontrando 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. 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 vincularme al servidor en SysPref y apareció brevemente la opción de nombre de servidor correcto y luego volvió a cambiar a "unknown-00-00-12-34-56-78.home" ¡justo frente a mis ojos!

En mi caso, tenía instalado OpenDNS en el pasado y no se eliminó limpiamente. Se estaban ejecutando varios procesos relacionados con dns, como DNSdnscrypt-proxy. No pude forzar el cierre de ellos en el Monitor de actividad, pero pude evitar que se iniciaran al reiniciar eliminando el archivo .plist en Biblioteca/LaunchDaemons.

Vaya a Configuración -> Red -> Avanzado -> DNS. Luego, haga literalmente cualquier cambio en el DNS (reordene sus entradas de 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 realizó 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

Desinstalar el cliente de roaming de Umbrella hizo que las búsquedas de DNS funcionaran bien para mí en Mac OS Mojave.

Ejecute la aplicación en

Applications > OpenDNS Roaming Client  > Umbrella Roaming Client Uninstaller.

Ejecutándose en MacOS Mojave 10.14.6. Principalmente los mismos problemas, como OP y otros. Todo funciona bien y, de repente, no hay acceso a Internet ni a direcciones locales. Puedo acceder por dirección IP pero no por DNS. Ni wifi ni conexión por cable. Claramente un problema de DNS. Puedo ver las entradas de DNS correctas en Preferencias de red... Avanzado... DNS. Hasta ahora la única resolución era un reinicio. Entonces funcionaría bien durante unos días, luego volvería a suceder.

Lo que funcionó para mí fue proporcionado arriba por @ user674669

function resetdns() {
 dscacheutil -flushcache;
 sudo killall -HUP mDNSResponder
 sudo killall -9 mDNSResponder mDNSResponderHelper
 sudo launchctl stop homebrew.mxcl.dnsmasq 
 sudo launchctl start homebrew.mxcl.dnsmasq

}

en funcionamiento

$ reinicios

Ejecuté cada línea en la función individualmente. Ahora veré si puedo escribirlo, ya que estoy bastante seguro de que lo necesitaré nuevamente.

Bien, tengo una resolución, pero la pregunta principal es ¿por qué sucede esto? Anteriormente, había intentado "sudo killall -HUP mDNSResponder" sin éxito, pero no había ejecutado los otros comandos. Puedo probar solo los primeros tres y ver si eso lo resuelve. Si requiere los dos comandos que hacen referencia a homebrew, ¿podría ser homebrew el problema?

Estoy seguro de que tendré otra oportunidad de comprobar esto más a fondo.

Nuevamente muchas gracias a @user674669!

Actualización 26-08-2021:

El problema volvió a ocurrir. Ejecutó solo los tres primeros comandos:

 dscacheutil -flushcache;
 sudo killall -HUP mDNSResponder
 sudo killall -9 mDNSResponder mDNSResponderHelper

... conexión probada después de cada uno. Parecía requerir los tres, no resuelve completamente el problema, solo restaura la funcionalidad de DNS hasta que vuelve a ocurrir.
El verdadero problema sigue siendo... ¿por qué sucede esto?

Y lo siento, puede que sea un novato aquí, pero también soy analista y lo he sido durante años. Creo que mis respuestas publicadas son relevantes para este tema. Nadie aquí ha llegado con una resolución concluyente definitiva a este problema. Y hago referencia a una respuesta diferente (pero también la misma) con respecto a la persona (@user674669) que brindó los pasos que pude usar para ayudar parcialmente (ya que el problema vuelve más adelante) a resolver el problema. Y con esta actualización, he determinado que no se requieren todos los pasos publicados por @user674669 (al menos en mi caso) para restaurar la funcionalidad de DNS. Creo que mis comentarios son útiles para otros que tienen este mismo problema.

LThibx

2022 y teniendo este problema.

nslookup & dig devolvió los valores dns correctos, pero ping y ssh al dispositivo deseado solo devolvieron la IP pública de mi dominio.

en mi caso, tuve que desactivar mi perfil de DNS y "el límite de seguimiento de direcciones IP" en el panel de preferencias de configuración de red.

ahora todo funciona correctamente y los dominios de búsqueda funcionan correctamente.

Después de actualizar Snow Leopard en una Mac Book antigua a Mountain Lion, el sistema no pudo resolver el DNS. Enjuagar, reiniciar, 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 la red DHCP. Rellenar este campo parecía alegrar el punto de acceso wifi. Dejarlo en blanco significaba que no pasaba nada, aunque la conexión wifi parecía tener éxito.