PingPlotter y los servidores DNS flaky de AT&T
Una de mis herramientas favoritas para rastrear problemas de red es una herramienta llamada PingPlotter publicada por Nessoft. He escrito sobre PingPlotter varias veces (la última vez en 2011, aunque también tuvo un papel protagonista en la resolución de mis problemas con AT&T en 2012). De hecho, esta utilidad me ha ayudado tantas veces que es ridículo. Aquí está mi resumen de PingPlotter de mi último resumen de mis herramientas favoritas:
El PingPlotter de Nessoft tests prueba la conectividad con uno o más hosts de destino en su red local o en Internet y traza los resultados. Lo que PingPlotter está haciendo en realidad es ejecutar repetidamente un trazador para identificar todos los enrutadores intermedios entre su máquina y los objetivos y probar cada uno durante cuánto tiempo tarda en responder. La herramienta también mide la «fluctuación de paquetes» (la variación en la rapidez con la que se manejan los paquetes), la Puntuación de Opinión Media de VoIP o MOS (una estimación de la calidad de voz percibida) y la desviación estándar del tiempo de tránsito de paquetes. Pingplotter viene en versiones freeware, Estándar ($24.95) y Pro ($199.95). Pingplotter gets obtiene una calificación de 5 de 5.
Recientemente tuve motivos para volver a usar PingPlotter cuando los dispositivos de mi red que configuraban sus conexiones de red a través de DHCP servidos por mi AT&T U-verse NVG-510 ADSL+ gateway comenzaron a ralentizarse.
En el registro de la NVG-510 (que es un registro circular que es demasiado corto) Vi varias ocurrencias de errores de DNS; por ejemplo, de hoy temprano:
2014-07-10T22:21:28-07:00 L3 dnsmasq: no responses from nameserver '99.99.99.53'2014-07-10T22:21:28-07:00 L3 dnsmasq: nameserver '99.99.99.53' is now responding
Con bastante frecuencia, estos errores ocurren en clústeres y los clústeres pueden continuar durante minutos a la vez, por lo que no es de extrañar que los dispositivos de mi red que usan configuraciones DHCP muestren una conectividad deficiente.
He teorizado anteriormente que la implementación de NVG-510 del reenviador de DNS de la puerta de enlace (que se basa en el código de código abierto dnsmasq) tiene un tiempo de espera demasiado corto en consultas fallidas. Pero, ¿por qué fallaría una consulta?
Inicié PingPlotter y descubrí que ambos servidores DNS están definidos e inmutables en el servidor DHCP de la puerta de enlace (es decir, servidores DNS primarios y secundarios al 99.99.99.53 y 99.99.99.153, respectivamente, que, de acuerdo con whatsmydns.net, no existen) siguen siendo, como observé en 2012, escamosos. El problema ahora parece ser que se han vuelto aún más escamosos.
Aquí hay una muestra de la salida de PingPlotter de ayer para los servidores DNS predeterminados de AT& T:
El tiempo entre pings es de 10 segundos y los bloques rojos más estrechos indican 1 paquete perdido. Como puede ver, hay pérdidas frecuentes de paquetes durante 20 o 30 segundos (los bloques de doble y triple longitud) o más. Estos clústeres de paquetes perdidos están, a su vez, en clústeres regulares, como se puede ver en este rastreo durante aproximadamente tres días y medio:
Por qué las respuestas del servidor deberían mejorar rutinariamente una vez al día es prácticamente un misterio por ahora.
Curiosamente, esos no son los únicos servidores DNS EN&T tiene otros servidores DNS primarios y secundarios en 68.94.156.1 y 68.94.157.1, respectivamente. El seguimiento de su comportamiento (las dos trazas inferiores), así como de los servidores DNS de Google en 8.8.8.8 y 8.8.4.4 (las dos trazas superiores) junto con los servidores DNS predeterminados (las dos trazas intermedias), muestra que se puede llegar de forma fiable a los servidores DNS a través de la red AT&T: