Bienvenido a nuestra web, en este lugar vas a hallar la respuesta que buscabas.
Solución:
Aquí está mi recomendación:
-
Veamos qué mDNSResponder en realidad está haciendo. Aquí hay una utilidad para activar/desactivar la censura detrás de la
-
Obtenga una captura de paquetes de su red a medida que realiza una solicitud de DNS. Tome Wireshark, inicie una captura en la interfaz que está usando (ya sea ethernet o WiFi; pero asegúrese de que los que no está usando estén apagados o desenchufados). Haría esto primero en el entorno donde toma 20-30 segundos, y luego nuevamente después de un reinicio cuando las condiciones son tales que solo toma 2-3 segundos. Cuanto menos pueda usar la red, mejor al ejecutar estas capturas de paquetes, ya que crecerán rápidamente. Esto debería mostrarnos la solicitud de DNS, así como las solicitudes hacia y desde los propios sitios web, para que podamos ver dónde están los retrasos. Si no hay retrasos en la red, entonces nos fijamos en los procesos.
-
Cargue las partes relevantes de los registros y/o las capturas de paquetes en algún lugar para que las veamos. Asegúrese de censurar o eliminar cualquier dato privado.
-
Y, finalmente, tenga en cuenta que esto puede resolverse más rápido haciendo una reinstalación del sistema operativo en el lugar. Eso puede oponerse a sus puntos de vista sobre ser capaz para reparar su equipo, saber qué sucede con su equipo, etc., pero si el objetivo es hacer que mDNSResolver vuelva a la cordura lo más rápido posible, una reinstalación del sistema operativo en el lugar puede ser el camino más rápido allí.
EDITAR: Pude volver a crear el problema y capturar el tráfico de red relacionado. Muchas secciones de RFC 6762 (Multicast DNS) parecen relevantes; no publicaré extractos aquí, pero específicamente encontré partes de las secciones 3, 5, 5.2 y 10.2, que son muy relevantes.
Esto es lo que creo que está sucediendo.
Al crear estos alias lo0, el tráfico se genera constantemente con un indicador de “descarga de caché”. El RFC no entra en suficientes detalles al respecto para estar seguro, pero parece que cada una de las direcciones de bucle invertido se anuncian a sí mismas como la dirección que puede responder a las consultas realizadas al nombre de host de la máquina y, por lo tanto, los dispositivos de escucha deben vaciar sus cachés internos y actualizarlos con la nueva dirección IP.
Piénsalo, si la red piensa que eres hostname.local en 192.168.44.111 y su dirección IP cambia, mDNS lanzará un mensaje de “vaciar sus cachés, hostname.local es ahora 192.168.44.123!” mensaje en 224.0.0.251. Esta es una circunstancia en la que mDNS anunciará de manera proactiva una nueva IP, y es la razón por la que la navegación en red funciona tan bien, es decir, las impresoras en red según el RFC.
Lo que no tiene mucho sentido para mí es que hay partes del RFC que me hacen pensar que varias direcciones de bucle invertido activas en la misma máquina no enviarían spam de la forma en que lo hacen, pero es posible que no entienda el RFC. bien. De cualquier manera, me parece claro que el mDNSResponder El proceso está recorriendo cada interfaz de bucle invertido y diciéndoles a todos en 224.0.0.251 para ignorar al último tipo que se hizo cargo, este es la nueva dirección IP asignada a mi nombre de host!
No tengo exactamente claro por qué esto ralentiza las consultas DNS regulares, excepto si mDNSResponder es responsable de enviar y recibir las consultas DNS regulares, bueno, está relacionado con todas estas tonterías con las otras interfaces. Y/o, tal vez, las consultas de DNS saldrían y volverían a entrar en la interfaz que se haya hecho cargo más recientemente del nombre de host. Eso, pude ver que realmente causaba retrasos, porque en el momento en que regresa una solicitud de DNS a través de WAN, la interfaz de bucle invertido que responde sería diferente de la que salió. Pero estoy escupir salvajemente en este punto.
Además, en lugar de tener que reiniciar, puede cambiar ligeramente su secuencia de comandos. Si ifconfig lo0 alias "$ADDR" up se usó para mostrar un nuevo alias de interfaz, luego
ifconfig lo0 -alias "$ADDR" puede usarse para derribarlo.
Nos encantaría que puedieras recomendar esta división si te fue útil.