Un dominio nacional dejó de resolver más de una hora
El dominio .al de Albania se rompió este mes. Durante más de una hora, las direcciones de todo el país dejaron de resolver: portales del Estado, medios y plataformas privadas por igual. Los ciudadanos no llegaban a los servicios públicos, y las empresas que operan bajo dominios albaneses sencillamente desaparecieron de internet. AKEP, la autoridad nacional de comunicaciones electrónicas y postales, señaló que el problema estaba en sistemas del extranjero que gestionan parte de la infraestructura de .al. La causa fue un cambio de clave DNSSEC fallido, ese mantenimiento criptográfico rutinario que se supone invisible.
Por qué importa. DNSSEC existe para demostrar que una respuesta DNS es auténtica. Cuando las firmas no validan, un resolutor bien configurado tiene que rechazar la respuesta por completo y devolver un error. Es el estándar funcionando exactamente como se diseñó. El modo de fallo de un control de seguridad que hace bien su trabajo es un país quedándose sin internet.
La solución fue apagar la seguridad
Nadie en el registro podía reparar las firmas a tiempo, así que la red esquivó el problema de la única manera que sabe. Cloudflare desactivó temporalmente la validación DNSSEC para .AL en su resolutor 1.1.1.1, y otros operadores hicieron lo mismo. El mecanismo se llama ancla de confianza negativa e indica al resolutor que trate una zona firmada como si no lo estuviera. Existe precisamente para estos incidentes. La resolución volvió. La validación no.
Cloudflare había expuesto la lógica sin rodeos durante un episodio idéntico en mayo: ningún usuario que esté resolviendo uno de esos nombres preferiría un error a una respuesta sin validar. Es casi seguro que sea cierto, y ahí está el problema entero. El control no falla en modo seguro ni falla en voz alta. Falla abierto, por convención del sector, justo en el momento en que un atacante más querría tenerlo apagado.
Diez semanas antes, a .de le pasó lo mismo
El 5 de mayo de 2026, hacia las 19:30 UTC, DENIC publicó firmas DNSSEC defectuosas para la zona .de. Los resolutores que validan estaban obligados a rechazarlas y devolver errores, y uno de los dominios de primer nivel más grandes de internet empezó a caerse. Los fallos crecieron durante tres horas mientras expiraban los registros en caché. La propia DENIC nombró la causa: un cambio de clave rutinario y programado durante el cual se generaron y distribuyeron firmas que no se podían validar. Los operadores de resolutores desplegaron anclas de confianza negativa en menos de una hora, y 1.1.1.1 tuvo su mitigación en pie a las 22:17 UTC.
Dos registros nacionales, con diez semanas de diferencia, derribados por mantenimiento programado y no por un atacante. Esta no es una historia sobre Albania, y no fue una historia sobre Alemania. Es el mismo fallo llegando dos veces, lo que lo convierte en un patrón y no en un accidente. Llegará una tercera vez.
Ahora el resolutor le dice cuándo dejó de comprobar
Lo genuinamente nuevo salió de este incidente. Junto al remedio, Cloudflare introdujo el Extended DNS Error 33, un código devuelto en la propia respuesta que señala que se omitió la validación DNSSEC. Hasta ahora, un resolutor que había abandonado la validación de una zona en silencio se veía idéntico a otro que seguía comprobando. Usted recibía una respuesta, la respuesta funcionaba, y nada en ningún sitio le decía que la garantía criptográfica detrás de ella estaba suspendida, quizá durante horas y quizá para todo un dominio de primer nivel.
Qué cambia. Ese silencio era la exposición real. Quien incluye DNSSEC en un registro de riesgos, en un cuestionario de seguridad o en un conjunto de controles de NIS2 venía afirmando algo que no podía observar. El EDE 33 convierte un estado invisible en uno registrado. Es un añadido pequeño a un paquete de respuesta y la primera señal honesta en este modo de fallo.
Qué hacer con una clave que usted no tiene
Lo incómodo es lo poco que está en su mano. Su zona puede estar firmada de forma impecable y su dominio desaparecer igualmente, porque la rotura ocurrió un nivel más arriba, en el registro que opera el sufijo de su país. NIS2 ya trata a los proveedores de servicios DNS y a los registros de dominios de primer nivel como entidades de alta criticidad, lo cual reconoce que esta capa es sistémica. No le da una palanca. Lo que sí puede hacer es dejar de dar por inerte esa capa: vigile si su propio dominio resuelve desde varios resolutores públicos y no solo desde la red de su oficina, y anote lo que esos resolutores le contestan.
La conclusión. Registre el EDE 33 y avise sobre él. Si su resolutor empieza a informar de que omitió la validación para su dominio de primer nivel, usted está en una ventana en la que las respuestas DNS de su dominio no están verificadas, y conviene saberlo mientras ocurre y no leerlo después. Dos países han atravesado ya esa ventana sin poder verla. El tercero tendrá al menos una luz encendida.
Leer a continuación: Cuatro agentes de código escaparon sin romper nada | El parche de nginx ya está, el exploit llega en agosto
