Resumen

  • Una investigación presentada en RIPE 93 midió siete servicios horarios. Microsoft operaba doce direcciones de servidor, pero más de la mitad de unos 9.000 puntos de observación RIPE Atlas recibían una sola dirección en la respuesta DNS.
  • En otra prueba, tres servidores de Microsoft mostraron desvíos durante horas; uno llegó a unos 40–50 milisegundos. Los ejemplos de protocolos de seguridad del estudio toleraban ese margen.

Pedir la hora a un solo reloj funciona hasta que ese reloj empieza a mentir. Entonces se agradece tener otro a la vista. El trabajo original de SIDN Labs, presentado en el programa de RIPE 93, encontró una curiosidad muy concreta: Microsoft contaba con doce servidores de hora y, aun así, su DNS entregaba una única dirección a la mayoría de los puntos donde se hizo la consulta.

Los investigadores observaron unos 9.000 puntos de RIPE Atlas. Ese es el tamaño de la muestra para el resultado de asignación, no un censo de ordenadores Windows. También examinaron Apple, Google, Ubuntu, AWS, Cloudflare y Meta. Tres de los siete servicios utilizaban anycast; cuatro recurrían en general a varias direcciones unicast. Tener muchos servidores y ofrecer varias opciones a cada cliente son decisiones distintas. La segunda se toma delante del usuario, en el mostrador DNS.

El RFC 8633 aconseja varias fuentes independientes. Con una sola, el cliente carece de un reloj de contraste cuando llegan segundos sospechosos. Los autores proponen que Microsoft devuelva al menos cuatro direcciones por cliente. Su inventario ya contiene doce; haría falta cambiar la selección que ve el cliente. La resistencia no se compra contando máquinas a kilómetros de distancia si el dispositivo recibe una lista de longitud uno.

La precisión se comprobó en un experimento diferente. Cuatro puntos sincronizados con GPS consultaron a los proveedores en ventanas de veinticuatro horas entre mayo de 2025 y junio de 2026. En una de esas campañas, tres servidores de Microsoft dieron la hora desviada durante varias horas; uno se apartó unos 40–50 milisegundos. El propio estudio explica que sus ejemplos de TLS, DNSSEC y RPKI toleran ese error. La cuestión operativa es la capacidad de detectar un fallo mayor antes de que el sistema lo adopte como referencia.

La ficha original de publicaciones de SIDN Labs fecha la versión ampliada en octubre de 2026. La investigación revisa además IPv6, DNSSEC, RPKI y Network Time Security, cuya especificación es el RFC 8915. Cloudflare reunía los cuatro componentes observados; Ubuntu también ofrecía NTS. Una hora en pantalla parece una cifra pequeña. La política de selección que la alimenta ocupa bastante más espacio.