Resumen
- Durante doce horas, unos 9.000 puntos RIPE Atlas consultaron DNS y encontraron 12 direcciones IPv4 para el servicio NTP de Microsoft; más de la mitad recibió solo una.
- La RFC 8633 recomienda al menos cuatro fuentes horarias independientes y diversas a quienes necesitan precisión. Las respuestas DNS que recibe cada cliente fijan cuántas fuentes puede comparar.
Análisis
El equipo preguntó directamente a los servidores DNS autoritativos cada diez minutos durante doce horas. Cerca de 9.000 puntos RIPE Atlas entregaron respuestas válidas desde 170 países. Para el servicio NTP de Microsoft, el estudio registró doce direcciones IPv4 en total. Más de la mitad de las sondas obtuvo una sola dirección distinta. En una campaña aparte de 60 días, los autores volvieron a observar las mismas doce direcciones de Microsoft.
Doce direcciones en el catálogo; una sola a la vista para la mayoría de las sondas. Esa diferencia entre la infraestructura que suma el proveedor y la respuesta que recibe cada punto de la red es el centro del trabajo de Pascal Huppert y otros siete autores en BigTime: Characterizing Large Time Service Providers, aceptado para CoNEXT 2026.
La RFC 8633, guía de buenas prácticas de NTP, recomienda al menos cuatro fuentes independientes y diversas para los operadores que buscan precisión. Fuentes que comparten operador, ruta o dominio de fallo pueden caer a la vez. Con una sola dirección recibida, el cliente carece de relojes distintos para hacer la comparación recomendada.
El conjunto de Atlas registra respuestas DNS desde los puntos de medición; el estudio no incluye registros por dispositivo Windows. Una IP puede estar delante de toda una flota, así que el recuento describe las opciones visibles para el cliente; el estudio no cuenta las máquinas físicas. En los lugares y el periodo medidos, la mayoría de las sondas recibió una única dirección de servicio. Desde esa respuesta, el cliente no puede contrastar los relojes de la flota como fuentes independientes.
La prueba de precisión, separada del censo DNS, usó cuatro puntos sincronizados con una referencia: SE-AWS en Suecia, US-AWS en Estados Unidos, JP-AWS en Japón y NL-SIDN en Países Bajos. Cada punto consultó las direcciones de Microsoft cada cinco minutos durante 24 horas. SE-AWS recibió 3.450 respuestas de 3.456 consultas; 199, el 5,8% de las respuestas recibidas, superaron el límite RTT/2. Según el método de los autores, con relojes sincronizados un desfase mayor que la mitad del tiempo de ida y vuelta no se explica solo por la demora de red.
Esas 199 respuestas se vincularon a tres servidores de Microsoft cuyos relojes estuvieron desajustados durante varias horas. En los otros tres puntos no hubo respuestas de Microsoft fuera del mismo límite. La tabla de SE-AWS registra −50,97 ms como el mayor desfase de los servidores afectados.
Pascal Huppert, doctorando en University of Twente, investiga la resiliencia y seguridad del ecosistema NTP. Su estudio cambia la pregunta: menos «¿cuántos servidores tiene el proveedor?» y más «¿cuántas respuestas distintas recibe el cliente?». La resiliencia se decide en esa frontera entre la política DNS y la lista de fuentes que usa cada dispositivo.
Fuentes
- Huppert et al., BigTime: Characterizing Large Time Service Providers, manuscrito aceptado — DOI 10.1145/3856960; las actas están previstas para diciembre de 2026.
- Perfil oficial de RIPE NCC y programa RACI de RIPE 93
- Ficha oficial de la sesión de RIPE 93
- RFC 8633, buenas prácticas para NTP
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para el Círculo Estratégico
Círculo Estratégico
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete al Círculo EstratégicoSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance





