El problema del bypass silencioso en DNSSEC
Cuando un TLD de país rompe su cadena de confianza DNSSEC, los resolvers validantes como el 1.1.1.1 de Cloudflare están obligados a rechazar todas las consultas de ese TLD. La solución operativa es conocida: instalar un Negative Trust Anchor (NTA), según la RFC 7646, que le dice al resolver que trate la zona como no firmada y se salte la validación.
¿El problema? Hasta hace poco, una respuesta servida bajo NTA era idéntica a una respuesta totalmente validada. Clientes, herramientas de monitoreo y aplicaciones no tenían cómo diferenciar una respuesta criptográficamente verificada de una que se sirvió con la validación suspendida.
Esa es exactamente la brecha que resuelve el trabajo reciente de Cloudflare con el EDE 33 (근거자료). Cuando el TLD .al (Albania) sufrió un rollover de clave DNSSEC roto en julio de 2026, el 1.1.1.1 se convirtió en el primer resolver grande en señalar la presencia de NTA dentro de la propia respuesta DNS.
Por qué esto importa para quien opera infra
Antes del EDE 33, la única forma de divulgación era out-of-band: una status page, un post en lista de correo o un blog. Eso requiere que el usuario vaya a buscar. Un sistema de monitoreo automatizado consultando el 1.1.1.1 no tenía forma programática de detectar que la validación DNSSEC se había saltado para un TLD entero.
Cómo funciona el EDE 33 en la práctica
Los códigos Extended DNS Error (EDE), definidos en la RFC 8914, permiten que los resolvers adjunten contexto extra a cualquier respuesta — éxito o falla. El nuevo código EDE 33, propuesto por Babak Farrokhi de Quad9 con Cloudflare como coautora, señala que un Negative Trust Anchor está activo para la zona consultada.
Checa esta respuesta real capturada durante el incidente del .al:
$ kdig @1.1.1.1 google.al
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 32848
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; EDE: 9 (DNSKEY Missing): 'no SEP matching the DS found for al.'
;; EDE: 33 (Negative Trust Anchor): 'a Negative Trust Anchor has been applied for this query (see RFC 7646)'
;; ANSWER SECTION:
google.al. 300 IN A 142.251.142.196
Leyendo la respuesta
status: NOERROR+ registro A válido — el dominio resuelve normal.- EDE 9 (DNSKEY Missing) — la cadena DNSSEC de fondo estaba rota; la validación falló.
- EDE 33 (Negative Trust Anchor) — el 1.1.1.1 aplicó un NTA y sirvió la respuesta igual.
Juntos, estos dos códigos dan visibilidad total: la respuesta es real, pero no fue validada por DNSSEC.
Detalle de comportamiento que vale la pena notar
El 1.1.1.1 devuelve EDE 33 en cualquier respuesta generada mientras un NTA está activo — incluso para dominios que no usan DNSSEC. Esto es intencional: el NTA cubre la zona completa, y la transparencia aplica uniformemente. También corrige un bug del incidente del .de (Alemania), donde el 1.1.1.1 devolvía EDE 22 (No Reachable Authority) en vez de exponer el error DNSSEC real.
Trade-offs y limitaciones que debes conocer
El EDE 33 es un mecanismo de señalización, no una corrección. Entender sus límites es clave antes de construir monitoreo encima.
| Aspecto | Qué hace el EDE 33 | Qué NO hace |
|---|---|---|
| Visibilidad | Informa que la validación se saltó | No restaura la protección DNSSEC |
| Alcance | Cubre la zona completa bajo NTA | No señala qué registros están afectados |
| Compatibilidad | Código asignado por IANA, reconocido por kdig | PR de Unbound sigue en revisión |
| Adopción | Cloudflare 1.1.1.1 se adelantó | Otros resolvers deben implementarlo |
| Fallback | EDE es opcional; hay que pedirlo vía EDNS | Clientes que ignoran EDNS no ven nada |
Advertencias críticas
- La zona queda sin firma durante el NTA. Todo dominio
.alperdió protección DNSSEC durante el incidente — el EDE 33 hace esto visible, no seguro. - Se requiere soporte del cliente. Si tu librería DNS o stub resolver no parsea EDE, recibes la respuesta sin el aviso. Audita tu stack:
dig,kdigygetdnsmoderno soportan EDE; muchos resolvers minimalistas no. - Hasta la publicación, el
.alsigue sin firma. El registro DS no se ha restaurado en la zona raíz por el operador del.al. Todo dominio.alsigue sin protección DNSSEC. - NTA es una respuesta operativa agresiva. Cloudflare solo lo aplica cuando la falla es pública, confirmada y afecta a todos los resolvers validantes por igual.
La lección más profunda
Las fallas DNSSEC a nivel TLD son raras, pero cuando pasan afectan a todos los dominios debajo simultáneamente. Los incidentes .de y .al, en secuencia dentro de dos meses, muestran que el herramental operativo para estos eventos sigue madurando. El EDE 33 es un paso para hacer el comportamiento del resolver auditable, no solo documentado.
Próximos pasos
Si operas infraestructura DNS o construyes herramientas de monitoreo, aquí está tu lista de acciones:
- Audita tu stack de resolver para soporte de EDE. Corre
kdig @1.1.1.1 <dominio> +ednsopt=15contra una zona bajo NTA conocida e inspecciona la salida. - Agrega parsing de EDE a tu monitoreo. Trata EDE 33 como señal de alerta distinta — significa "resolviendo, pero no verificado".
- Sigue el Internet-Draft. La propuesta se envió al IETF DNSOP Working Group y se discutirá en la reunión de Viena (18–24 de julio). El feedback va a la lista DNSOP.
- Entiende el trade-off del NTA antes de pedirle a tu resolver que aplique uno. Suspender la validación DNSSEC es una decisión real de seguridad, no un toggle de conveniencia.
Lectura relacionada
- How Blockchain is Revolutionizing Agricultural Traceability: A Deep Dive into Tokenized Cotton — un vistazo a cómo los modelos de confianza distribuida se aplican fuera del DNS.
- Dynamic Path MTU Discovery: How Cloudflare Eliminates Network Black Holes for Good — otro deep dive de Cloudflare en modos silenciosos de falla de red y cómo exponerlos.
La transparencia en DNS está evolucionando rápido. El EDE 33 es un código pequeño con una implicación enorme: los resolvers ya no pueden tomar decisiones silenciosas sobre tu tráfico.