La búsqueda DNS de Mac OS X parece estar desordenada, pero solo en el trabajo

Las búsquedas DNS de Mac OS X tardan una eternidad en Safari y otras aplicaciones que usan mDNSResponder. Las mismas búsquedas funcionan bien si uso nslookup desde la línea de comandos, y también funcionan bien desde mi iPhone y iPad en la misma red inalámbrica.

Y eso solo está en la red en el trabajo; Cuando estoy en casa o conectado a mi iPhone, todas las búsquedas de DNS funcionan bien. Cuando estoy en la red en el trabajo, ya sea a través de Wi-Fi o Ethernet, tengo estos problemas. He intentado usar los siguientes comandos:

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

Eso solía proporcionar un alivio temporal (minutos) bajo Snow Leopard, pero ahora, bajo Lion, generalmente no proporciona nada en absoluto.

Ni mi configuración de Ethernet ni la de Wi-Fi especifican servidores DNS; se llenan automáticamente desde el enrutador. Pero he intentado especificar el mío, como Google DNS o OpenDNS, y eso no soluciona el problema.

La configuración de la red es un enrutador conectado al cable módem, con todos los puertos Ethernet en la oficina saliendo de él. Un enrutador wifi Airport Extreme también está conectado al enrutador principal (en modo puente), y los clientes WiFi se conectan a eso.

He buscado por todas partes y he encontrado otras cosas que parecen aplicables al principio (por ejemplo, la búsqueda de DNS falla pero nslookup funciona ), lo que me hace pensar que estos problemas de mDNSResponder no son demasiado infrecuentes, pero ninguno de ellos coincide exactamente y sus soluciones no lo han hecho. funcionó para mí todavía.

Además: no todas las búsquedas de DNS, solo la mayoría. Las búsquedas de Google aparecen instantáneamente, pero Google Maps tarda una eternidad en cargarse (cuando miro la ventana de actividad, generalmente son scripts y lo que no proviene de algún servidor CDN de Google). Incluso los sitios que usamos todos los días, y pensaría que estarían almacenados en caché en algún lugar (como php.net) tardan una eternidad en cargarse, o se agota el tiempo de espera.

Además: todo se carga bien desde un navegador dentro de una máquina virtual con Windows XP, lo que para mí apunta aún más acusadoramente a mDNSResponder como el culpable, pero todo funciona bien cuando estoy en cualquier otra red.

La razón por la cual el DNS es lento en la oficina pero no en el hogar, podría ser que el enrutador de la oficina usa IPv6 pero el enrutador de su casa usa IPv4, y que Lion es mejor usando IPv6 que Snow Leopard. Los sitios web que no se ven afectados por esa desaceleración son probablemente los que tienen un mejor soporte para IPv6.

Consulte este artículo para conocer las medidas que muestran que IPv6 es 2-3 veces más lento que IPv4 en DNS: IPv6 lo ralentizará
(DNS)

Si ese es el caso, deshabilitar IPv6 en el enrutador de la oficina (y así en toda la red de la oficina) podría resolver el problema.

Este artículo también puede ser útil: Cómo deshabilitar IPv6 en Mac OS X 10.7 Lion .

Solía ​​tener el mismo problema con mi MacBook Pro con 10.6. Raramente apago mi máquina. Básicamente en casa solo cierro la tapa y la guardo en mi bolso y la llevo al trabajo. En el trabajo abro la tapa y me voy. Lo que he notado es que OS X no parece hacer esta transición tan fácilmente como me gustaría. Obtendría un DNS lento, grandes cantidades de recursos de red en espera, etc. Lo que me soluciona es desconectarme manualmente de cada red antes de cerrar mi máquina (es decir, apagar el aeropuerto antes de cerrar la tapa). Si no hago esto, mi modo de espera es:

dscacheutil -flushcache

De cualquier manera funciona bastante bien para mí. En una rara ocasión reinicio la máquina.

¿Otras Mac funcionan correctamente en la red de la oficina?

Asegúrese de que la configuración de red asignada sea coherente. He visto la situación en la que un servidor DHCP estaba asignando una puerta de enlace predeterminada que no estaba en la subred del cliente. Windows siguió adelante y usó eso, y funcionó bien, pero MacOS (¡correctamente!) Se negó a enviar a una dirección IP que no estaba en la subred.

Cuando la máscara de subred se aplica tanto a la dirección IP del cliente como a la puerta de enlace predeterminada, los resultados deben ser iguales. De lo contrario, es una mala configuración del servidor DHCP.

Sin embargo, esto no parece esa situación exacta. ¿Está su Mac configurada para usar tanto WiFi como Ethernet en el trabajo? Si es así, intente apagar uno a la vez.