Redes

1.1.1.1 y EDE 33: qué te está diciendo de verdad cuando falla DNSSEC

Publicado el 19/07/2026 Análisis y guía práctica en su-ip.es

Cloudflare añade EDE 33 en 1.1.1.1 para avisar cuando una respuesta DNS sale adelante bajo un Negative Trust Anchor. Te contamos qué significa y qué conviene revisar.

Cloudflare ha convertido un incidente DNSSEC real en una mejora práctica para quien usa 1.1.1.1. Tras el fallo del dominio de nivel superior .al el 3 de julio de 2026, su resolver público empezó a devolver EDE 33 cuando una respuesta sale adelante gracias a un Negative Trust Anchor o NTA. Dicho en castellano simple: si un dominio responde, pero la validación DNSSEC se ha saltado temporalmente para mantenerlo accesible, ahora 1.1.1.1 puede decírtelo.

Eso importa bastante más de lo que parece. Hasta ahora, muchos fallos DNSSEC acababan resumidos en un SERVFAIL poco útil, o al revés: una respuesta aparentemente normal sin señal clara de que el resolver había tenido que relajar la validación. EDE 33 añade contexto operativo real para administradores, herramientas de monitorización y equipos que quieren distinguir entre “todo va bien” y “el dominio resolvió, pero con una excepción temporal”.

Resumen rápido: qué ha pasado y por qué importa

3 de julio de 2026: el operador de .al intentó un DNSSEC key rollover y rompió la cadena de confianza.
Los resolvers validadores, incluido 1.1.1.1, empezaron a devolver errores al no poder validar el TLD.
Cloudflare aplicó un NTA para mantener la resolución accesible mientras duraba la incidencia.
La novedad publicada por Cloudflare el 14 de julio de 2026 es que 1.1.1.1 ya devuelve EDE 33 para dejar visible esa excepción.
La idea no es “quitar” DNSSEC, sino hacer transparente cuándo se ha tenido que puentear temporalmente.

Qué significa EDE 33 en una respuesta DNS real

RFC 8914 define los Extended DNS Errors, un mecanismo para añadir contexto a respuestas DNS que, por sí solas, suelen decir muy poco. En vez de ver solo un error genérico o un NOERROR desnudo, el cliente puede recibir una pista mucho más útil sobre lo que ha pasado.

En este caso, EDE 33 significa “Negative Trust Anchor”. La entrada ya aparece asignada en el registro de IANA, y la propuesta específica está activa en el IETF DNSOP. Lo importante para quien opera redes no es la trastienda burocrática, sino esto: si 1.1.1.1 entrega una respuesta con EDE 33, te está avisando de que el dominio se resolvió bajo una excepción temporal de validación DNSSEC.

Ese matiz cambia bastante la interpretación de una incidencia. Ya no es solo “resuelve” o “no resuelve”. Ahora puede ser también “resuelve, pero no con la garantía criptográfica habitual”. Para equipos de observabilidad, soporte o seguridad, esa diferencia merece alerta, documentación y seguimiento.

Qué es un NTA y por qué no conviene confundirlo con una solución definitiva

Un Negative Trust Anchor, definido en RFC 7646, permite a un resolver validar menos en una zona concreta cuando la firma DNSSEC está rota por un error operativo. El objetivo es evitar que medio Internet deje de llegar a un dominio legítimo por una mala rotación de claves o una DS inconsistente.

Eso sí: un NTA no es un parche bonito ni una mejora de seguridad. Es una medida agresiva y temporal para mantener servicio mientras se corrige la avería. Si tu monitorización detecta EDE 33, la lectura correcta no es “ya está arreglado”, sino “la disponibilidad se ha salvado, pero la validación DNSSEC está suspendida en esa zona durante ese periodo”.

Ingeniero de redes analizando una incidencia DNSSEC con trazas DNS y detalle de EDE 33 en varios monitores — Con EDE 33, una incidencia DNS deja de ser una caja negra: el resolver puede señalar que la respuesta salió bajo una excepción temporal.

Qué ocurrió con .al exactamente

Según explica Cloudflare, AKEP, el operador del TLD .al, publicó una nueva DNSKEY y dejó de servir la anterior, mientras la DS del root seguía apuntando a la clave vieja. Eso rompió la cadena de confianza y cualquier resolver validador pasó a considerar la zona como inválida.

Más tarde, el operador eliminó la nueva clave sin restaurar la anterior, y finalmente quitó la DS del root. Durante esa ventana, Cloudflare desplegó un NTA a las 17:15 UTC del 3 de julio de 2026 para que los dominios .al siguieran resolviendo en 1.1.1.1. Lo nuevo no es solo la maniobra operativa, sino que ahora el resolver deja rastro explícito de esa decisión con EDE 33.

Qué revisar si administras DNS, monitorización o servicios dependientes de resolvers públicos

Tu herramienta de diagnóstico DNS: confirma si dig, kdig o tu librería ya muestran EDE con claridad.
Alertas de disponibilidad: distingue entre NOERROR limpio y NOERROR con contexto EDE relevante.
Dependencia de un único resolver: si todo tu monitoreo se basa en un solo proveedor, documenta cómo interpretarás estas excepciones.
Runbooks de soporte: añade una nota específica para incidentes DNSSEC con NTA, porque no equivalen a una resolución normal.
Observabilidad de terceros: revisa si tus paneles, SRE checks o robots externos capturan el EDE o se quedan solo con el código principal.

Para entornos pequeños, esto también tiene lectura práctica. Si usas 1.1.1.1 en casa, en un pequeño negocio o en un homelab, probablemente no vas a cambiar tu operación por EDE 33 todos los días. Pero si te gusta entender por qué un dominio falla a ratos o por qué tu sistema de chequeo no ve lo mismo que otro resolver, este detalle te evita mucho diagnóstico a ciegas.

La idea encaja bastante bien con el tipo de red que solemos comentar en nuestra guía para configurar un router Movistar o al hablar de Wi‑Fi 8 centrado en estabilidad real: la red no mejora solo con más velocidad o con más marketing, sino con señales más claras cuando algo se rompe.

Rack de red y portátil mostrando salud del resolver y validación DNSSEC en un pequeño laboratorio doméstico — Incluso en una red pequeña, saber si una respuesta vino con una excepción DNSSEC puede ahorrar bastante tiempo de diagnóstico.

Qué no significa EDE 33

No significa que el dominio sea malicioso.
No significa que DNSSEC sea inútil o que convenga desactivarlo.
No significa que la respuesta sea falsa por defecto.
Sí significa que el resolver tuvo que apartarse temporalmente de la validación normal para mantener accesibilidad.

Ese matiz es justo el que faltaba en muchas incidencias. Entre un SERVFAIL opaco y una respuesta aparentemente normal había demasiada información perdida. EDE 33 rellena ese hueco y permite a clientes, scripts y operadores decidir mejor qué hacer con lo que están viendo.

FAQ rápida

Si uso 1.1.1.1, tengo que cambiar algo hoy?

No necesariamente. La mejora es sobre todo de visibilidad y diagnóstico. Lo útil hoy es saber interpretarla y comprobar si tus herramientas muestran los EDE correctamente.

EDE 33 sustituye a DNSSEC?

No. DNSSEC sigue siendo la validación principal. EDE 33 solo avisa de que, temporalmente, esa validación se ha bypassado con un NTA.

Por qué es mejor ver EDE 33 que recibir un simple SERVFAIL?

Porque reduce la ambigüedad. Un SERVFAIL puede venir por muchas causas. EDE añade una pista concreta sobre el motivo o el contexto operativo.

Esto afecta solo a grandes operadores?

No. También afecta a quien monitoriza webs, dominios, APIs o correo desde resolvers públicos y necesita entender incidencias de resolución con algo más de precisión.

Fuentes oficiales

Conclusión

La novedad no es que 1.1.1.1 “rompa” DNSSEC, sino que deja de ocultar cuándo ha tenido que hacer una excepción temporal para mantener una zona accesible. En un ecosistema donde muchas incidencias DNS parecen iguales desde fuera, EDE 33 aporta la clase de contexto que sí sirve para soporte, observabilidad y operaciones reales.

Si trabajas con redes, dominios o monitorización, merece la pena recordar esta idea: que una web responda no siempre significa que todo esté sano. A partir de ahora, al menos con 1.1.1.1, tienes una pista más clara para distinguir ambas cosas.