Tell HN: Microsoft.com añadió 192.168.1.1 a su registro DNS
Una mala configuración añadió brevemente direcciones IP privadas (192.168.1.0/1) a los registros DNS públicos de microsoft.com, lo que hizo que las solicitudes de algunos usuarios pudieran resolverse hacia sus propios routers domésticos o dispositivos locales en lugar de los servidores de Microsoft. Los comentaristas analizan el impacto operativo (timeouts, pérdida parcial de tráfico, retrocesos a IPv6), las implicaciones de seguridad en torno a DNS rebinding y la emisión de certificados, y cómo un error así pudo colarse en el control de cambios de una gran empresa. El incidente también provoca reflexiones más amplias sobre los mecanismos de seguridad de DNS, las protecciones del lado del resolutor frente a respuestas con direcciones privadas y las barreras organizativas para evitar errores similares.
Qué pasó
microsoft.comtuvo brevemente registros A que apuntaban a192.168.1.1y192.168.1.0, ambas direcciones privadas RFC1918.- Muchos usuarios confirmaron ver estos registros mediante consultas DNS; una dirección desapareció primero y la otra permaneció un tiempo más.
- Los registros erróneos fueron eliminados más tarde de los servidores de nombres autoritativos, pero los resolutores públicos tardaron en vaciar sus cachés.
Efectos inmediatos e impacto en los usuarios
- Con 2 de 7 registros A siendo IP privadas, algunos clientes resolvían aleatoriamente
microsoft.comhacia dispositivos locales (a menudo routers domésticos o impresoras). - Los síntomas incluyeron timeouts, fallos de conexión o abrir una página de administración del router en lugar del sitio de Microsoft.
- Algunas configuraciones de DNS (por ejemplo, con protección contra DNS rebinding) bloquearon las respuestas, dejando a
microsoft.comefectivamente solo con IPv6 o inaccesible en esas redes.
Preocupaciones de seguridad y modelos de amenaza
- Varios comentarios subrayaron que esto supone principalmente un riesgo para Microsoft, no para las redes de los usuarios finales.
- Riesgos potenciales discutidos:
- Si un actor malicioso hubiera controlado una IP pública en lugar de una privada, podría haber interceptado parte del tráfico o intentado phishing.
- Posibilidad de usar validación de dominio basada en HTTP para obtener certificados, aunque esto requeriría bastante control y un enrutamiento correcto del tráfico.
- Otros señalaron protecciones: HTTPS, actualizaciones firmadas y servidores DNS que rechazan IP privadas en respuestas públicas como defensa contra DNS rebinding.
- Algunos señalaron que el uso indebido de
microsoft.comde esta forma podría haber sido más peligroso si un atacante o un actor estatal lo hubiera planificado cuidadosamente.
¿Cómo pudo ocurrir esto? (Especulación dentro del hilo)
- Las teorías incluyeron: error de copiar y pegar, fallos de automatización o de IaC, configuraciones de dev/test filtradas a producción, o fallos generales de ClickOps/proceso.
- Algunos dudaron de que personal de nivel inicial pudiera cambiar una zona tan crítica, sugiriendo una canalización más compleja o un fallo de revisión.
Proceso, cultura y lecciones
- Llamadas a mejores barreras de protección: validación para bloquear RFC1918 en grandes zonas públicas, revisiones con doble control y comprobaciones automatizadas.
- Reacciones mixtas: algunos lo ven como un error inofensivo pero embarazoso; otros lo consideran un serio fallo de proceso para una dependencia crítica de Internet.