DNS no se resuelve en Mac OS X

101

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
CajunLuke
fuente
Me pasa también en el león.
dkagedal
Pasando por mí en Mavericks, 10.9.4
greg7gkb
Esto parece un problema histórico que pudrió la vida de los usuarios y administradores de red de Leopard a Yosemite. Si alguien todavía ve este problema, informe claramente si tiene más de una interfaz activa y, además, obtiene su conf. desde un servidor DHCP (desde diferentes lados). ¿Por qué? Nunca vi un problema así en ningún otro Unix ni en ninguno de mis Mac (tengo muchos), pero ninguno de ellos tiene más de una interfaz que se dirija a una fuente de información de DNS.
dan
Intente cambiar su configuración de DNS (cambiar el orden o eliminar entradas), eso resuelve el mismo problema para mí
mems

Respuestas:

91

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.

CajunLuke
fuente
55
Pero esta no es realmente una respuesta satisfactoria. Necesito saber cómo evitar que suceda en primer lugar.
dkagedal
1
@dkagedal En realidad, esta es una respuesta tan buena como la que vamos a obtener: esto sucede porque su Mac almacena en caché las entradas DNS para evitar golpear su servidor DNS (probablemente su enrutador) para cada búsqueda de DNS, lo que sucede mucho. Este caché es necesario y bueno, pero sería bueno si hubiera un mejor comportamiento cuando no se encuentra una entrada (lo considero un error). En cualquier caso, hay un tiempo de espera en la memoria caché; Cuando esperé unos 10 minutos en mi máquina, esta situación se resolvió por sí sola. Para la mayoría de los usuarios, el comportamiento existente está bien, por lo que Apple probablemente no lo cambie pronto.
Matt
2
Por supuesto, esto no es tan bueno como parece. Ningún otro sistema operativo tiene este problema. No hay nada malo con el DNS, el registro de www.google.com no se perdió, es solo el caché de MacOS que de alguna manera lo perdió y no lo recuperará. Y ese es un error que necesita reparación.
dkagedal
1
Tengo este problema en 10.9 y la solución funcionó perfectamente. En mi caso, el DNS estaba resolviendo los nombres completos pero no los cortos.
sorin
1
@ Matteo Tal vez el archivo no tenga que existir, o tal vez la respuesta deba actualizarse para Yosemite. ¿Tienes este problema? ¿Ejecutar esos comandos lo arregla?
CajunLuke
10

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  
chiggsy
fuente
3
No explica por qué estos comandos ayudarían con este problema. ¿Incluso? ¿O esto significa un comentario a una de las otras respuestas o algo así?
dkagedal
Una posible ventaja de scutil es que podría funcionar independientemente de si la computadora ha descubierto o mDNSResponder. Data de antes de su introducción.
DA Vincent
1
estos comandos no resuelven el problema
Radu Simionescu
7

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.

Martin Marconcini
fuente
Vea mi edición de la pregunta.
CajunLuke
@CajunLuke hmmmm interesante ... ¿Me importaría agregar el resultado de: cat /etc/resolv.conf a su pregunta?
Martin Marconcini
Editado (Relleno para que el comentario encaje.)
CajunLuke
@CajunLuke estoy perplejo. Volvamos a las raíces ... esto solo sucede en esta máquina, y solo en OSX, las máquinas virtuales están bien. Estoy empezando a sospechar que Parallels o VMware pueden estar causando algunos problemas. ¿Qué tipo de red utilizan estas máquinas virtuales? Puenteado? ¿Compartido?
Martin Marconcini
1
O si quieres realmente corto, siempre puedes hacer ... cavar + corto un apple.com ...
Pryftan
7

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.

David Wolever
fuente
Solo me gustaría señalar que después de 16 horas seguidas explorando Internet, esta es la única solución que he encontrado que me permite resolver los nombres internos de la compañía Y permite que las redes divididas funcionen correctamente. Muchas gracias por hacer este comentario.
Ron Thompson
También señalaría que en OS X El Capitan, para configurar este script, envolví mi openconnectcomando en un script de Python, junto con comandos como networksetup -setdnsservers 127.0.0.1y networksetup -setsearchdomains "$COMPANY_NAME".com. ¡Agregue su dnsmasqcomando y todo está listo! Finalmente tengo una solución VPN estable gracias a este comentario.
Ron Thompson
Para los futuros lectores, me pareció más fácil simplemente ingresar a mi caja en el trabajo, determinar qué IP tenía para los servidores de nombres y luego codificar esas IP en mi resolv.conf debajo de 8.8.8.8 (busca el servidor DNS). Eso permite que todos los nombres que no sean de la compañía se resuelvan correctamente sin tener que pasar por los servidores de la compañía, lo que me parece útil para la privacidad y la velocidad. En lo que respecta al hardcoding, esas IP no cambiarán en el corto plazo, y si lo hacen, no seré el único afectado y debería ser trivial editar dos líneas.
Ron Thompson
Dice que la dirección 127.0.0.1 ya está en uso, cuando intento iniciar dnsmasq. ¿Que tengo que hacer? High Sierra
IceFire
@IceFire Sé que esto es antiguo, pero eso significa que ya hay un servicio vinculado a ese puerto (53). Técnicamente, eso significa que está recibiendo el error EADDRINUSE pero no iré allí :) En cuanto a esta respuesta, me resulta intrigante. Tengo un problema similar pero creo (espero) que la otra respuesta lo resuelva solo que no necesito habilitarlo al menos para mi red doméstica ya que tengo mis propios servidores DNS autorizados (y uno es local y lo que uso). Otoh como usuario de Unix desde hace mucho tiempo, el hecho de que pueda usar /etc/resolv.conf es atractivo, pero probaré el otro primero.
Pryftan
6

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.

cacahuetes congelados
fuente
1
Mi empresa ha tenido este problema durante meses y meses, cada vez que llevaba Macs a la "barra Genius", cuya única solución era borrar los discos duros y comenzar de nuevo. Vi tu publicación, eliminé com.apple.mDNSResponder.plist, reinicié y el problema se resolvió. Desearía poder votarte mil millones de veces.
Thomas Thorogood
1
¡Nota eliminar com.apple.mDNSResponder.plist! Lo hice como sugirió @TomThorogood. Tengo dificultades para volver. Incluso cuando puse el archivo de nuevo y reinicié, no pude obtener ninguna respuesta de Internet. El sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistque ayudó.
Pavel Binar
5

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.

Simon C Smith
fuente
4

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.

Brian de Alwis
fuente
1
Esta fue la solución para mí también en Yosemite. Algunos detalles: host, dig y Chrome funcionaron bien, pero ping, telnet, ssh, firefox y safari no pudieron resolver los nombres de host. Esta solución solucionó mi problema.
Ryan Hoegg
Esto me molesta todo el tiempo. Tiene que reiniciar el servicio.
Callum Rogers
2

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

DKroot
fuente
2

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

Dustin Matlock
fuente
1
Tal vez deberíamos mencionar support.apple.com/en-au/HT203244 .
DA Vincent
@DAVincent Unos años tarde, pero ese enlace es decepcionante. Es claramente un error de Apple, pero lo atribuyen al error del usuario.
weberc2
2

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.

rexford
fuente
2

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.

Score_Under
fuente
2

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.

kenorb
fuente
1

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.

Lukasz Madon
fuente
1
Aunque la pregunta puede necesitar alguna edición, todavía dice (en el momento de escribir este comentario) que los trabajadores ya intentaron apagar y volver a encender el Wi-Fi. ¿Quizás podríamos retractar esta respuesta?
DA Vincent
No tengo suficiente reputación para agregar un comentario a una publicación sobre cómo apagar y encender wifi, pero eso funcionó para mí. Retirar la respuesta sería una tontería.
+1 para la sugerencia de volver a intentarlo. Las respuestas múltiples ayudan a muchas personas, y cada enrutador tiene diferentes tiempos de espera y comportamientos.
bmike
1

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.

Jérémie
fuente
Muchas gracias, este fue mi problema. He estado depurando durante horas, y cuando busqué en / etc / resolver, por supuesto, encontré un archivo llamado "prueba", con las direcciones IP erróneas ...
keyer
1

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>
sMyles
fuente
0

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.

Yeison
fuente
0

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!

cwj73
fuente
0

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/

andilabs
fuente
0

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.

Hao
fuente
0

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
weberc2
fuente
0

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

Marcelo
fuente
-1

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.

xt1
fuente