Cómo las Fallas de DNS Causan Tiempo de Inactividad Invisible

Las plataformas de observabilidad están diseñadas para rastrear lo que hacen sus sistemas. Pero ¿qué sucede cuando ocurre una interrupción antes de que una solicitud llegue al borde de su infraestructura? Sus paneles informarán con confianza un 100% de tiempo de actividad, mientras sus clientes experimentan un apagón implacable.

El Dilema del 'Split-Horizon'

La razón por la que sus métricas mienten se debe a la naturaleza de horizonte dividido de las redes en la nube. Sus pods internos de Kubernetes resuelven los puntos finales del servicio utilizando un resolver de VPC privado. Dado que la red interna es prístina, las pruebas de salud son exitosas.

Pero los clientes externos confían en la cadena de resolución recursiva de la Internet pública para descubrir su Ingress público.

Cuando la Puerta Desaparece

Una falla 'invisible' ocurre cuando los registros autoritativos públicos se interrumpen. Un ejemplo fue la caída de Slack en 2021: una configuración eliminó accidentalmente todos los registros A para sus API principales.

Internamente, los servidores de Slack funcionaban, procesando trabajos en segundo plano. Pero ningún cliente nuevo podía resolver el dominio 'slack.com'. Internet simplemente olvidó dónde estaba alojado Slack.

Aislando la Brecha

Para demostrar esta discrepancia, puede escribir un script de prueba simple. Fuerza explícitamente una consulta DNS contra el servidor autoritativo público:

nslookup -debug tudominio.com ns1.tu-proveedor-dns.com

Si este comando expira, su capa autoritativa es defectuosa, independientemente de lo que diga su herramienta interna.

Conclusión

Al diseñar su postura de confiabilidad, nunca confíe en una prueba de salud interna para validar la accesibilidad externa.