El incidente de .AL fue causado por un error en el proceso de key rollover de DNSSEC por parte del operador del TLD. Al publicar una nueva DNSKEY y eliminar la antigua sin actualizar el registro DS correspondiente en la zona raíz, se rompió la cadena de confianza DNSSEC. Esto provocó que cualquier resolver DNSSEC validador rechazara las respuestas para dominios .AL, resultando en errores SERVFAIL y la inaccesibilidad de sitios web críticos.
La cascada de fallo se manifestó a medida que los registros DNS en caché expiraban, forzando a los resolvers a intentar (y fallar) la validación DNSSEC. La falta de respuesta del operador de .AL, exacerbada por el hecho de que sus propias direcciones de contacto estaban bajo el TLD afectado, impidió una resolución rápida. Cloudflare, como operador de un resolver DNS público, tuvo que intervenir con un Negative Trust Anchor (NTA) para restaurar la accesibilidad, aunque esto implicó suspender temporalmente las protecciones DNSSEC.
Las salvaguardas existentes, como la especificación DNSSEC que exige el rechazo de respuestas no válidas, funcionaron según lo diseñado, pero esto llevó a una interrupción generalizada. La ausencia de un mecanismo estándar para comunicar a los clientes que la validación DNSSEC había sido omitida por un NTA fue una deficiencia clave. Cloudflare abordó esto introduciendo el código EDE 33, que proporciona transparencia sobre la aplicación de NTAs, permitiendo a los clientes entender por qué una respuesta fue servida sin validación DNSSEC.