Resumen

  • La RFC 8914 define EDE como la opción EDNS 15: INFO-CODE de 16 bits y texto UTF-8 opcional. Puede aparecer varias veces y junto a cualquier RCODE, pero nunca sustituye las reglas del RCODE base.
  • Un EDE puede ser no autenticado, eliminado o recreado por un forwarder. Cifrar el tramo hasta el resolver identifica mejor al emisor, pero no prueba que su diagnóstico sea correcto.
  • La automatización debe conservar paquete, orden de códigos, procedencia, validación, caché, regla local y reacción del cliente. La etiqueta decide qué comprobar, no qué defensa apagar.

El fallback que arregló el síntoma y perdió la seguridad

Una aplicación móvil consulta un nombre firmado. El resolver corporativo devuelve SERVFAIL y EDE 6, DNSSEC Bogus. El sistema operativo, programado para buscar disponibilidad, pregunta a un segundo resolver que no valida y recibe una dirección. La pantalla vuelve a funcionar; la propiedad de seguridad desaparece.

EDE se diseñó en parte para evitar esa ceguera. Conocer que el primer fallo procede de validación permite detener el retry indiscriminado y buscar una firma caducada, una clave ausente, un reloj incorrecto o una cadena DS/DNSKEY rota. Sin embargo, el código sigue siendo la explicación de un resolver. Un atacante on-path puede insertarlo en DNS no protegido; un resolver malicioso puede mentir aun sobre un canal autenticado; un software correcto puede clasificar mal.

El control adecuado mantiene el fallo, consulta otros validadores independientes y compara la evidencia criptográfica. Sólo después se corrige la zona, el reloj o el estado local. Cambiar a datos inseguros porque la etiqueta menciona DNSSEC confunde diagnóstico con permiso.

Lo que viaja en la opción 15

EDE usa un INFO-CODE de dos octetos. El resto es EXTRA-TEXT UTF-8 para lectura humana, no para parsing automático. OPTION-LENGTH marca el final: el texto puede estar vacío y no hay garantía de terminación nula.

Puede acompañar NOERROR, NXDOMAIN, REFUSED, SERVFAIL u otro RCODE. También puede aparecer más de una vez. El receptor ha de aceptar la multiplicidad aunque no actúe sobre ella. La RFC advierte que ciertas combinaciones parecerán absurdas; por eso obliga a seguir procesando el RCODE según su propia especificación.

Esta obligación contiene el poder del nuevo vocabulario. EDE añade contexto, pero no vuelve auténtica una respuesta, no cambia SERVFAIL por éxito y no concede a una política local autoridad sobre la zona. Si el paquete supera el tamaño UDP anunciado, la información EDE debe descartarse antes que otros datos y debería activarse TC. Que no llegue una explicación tampoco demuestra que el emisor no la tuviera.

La procedencia se rompe al reenviar

Un forwarder puede omitir el EDE recibido o generar uno nuevo para su cliente. Si lo transmite o reformula, debería atribuir la fuente en el texto porque el último paquete parece hablar en nombre del último servidor. Esa atribución sigue siendo prosa sin firma.

El registro de evidencia separa quién observó, quién clasificó, quién redactó y quién transmitió. Añade endpoint, transporte y autenticación del peer. DoT, DoH y DoQ protegen un tramo; DNSSEC protege datos bajo su cadena. Ninguno certifica por sí solo una inferencia operativa de un resolver.

Cuando llegan varios códigos, su orden y origen importan. Stale Answer puede describir el dato entregado mientras No Reachable Authority explica por qué se recurrió a él. Aplanarlos en una sola causa pierde la relación. Un código de filtrado creado por un RPZ local no debe atribuirse al authoritative server.

IANA evita colisiones, no califica testimonios

La RFC 8914 creó los códigos iniciales 0–24. El registro IANA observado en agosto de 2026 contiene asignaciones posteriores y referencias de madurez diferente. La política First Come First Served de la franja pública facilita la interoperabilidad numérica; la franja alta queda para uso privado.

La inscripción prueba que un número tiene una descripción compartida. No prueba que el evento ocurrió, que el emisor eligió bien, que la referencia es un estándar ni que un cliente deba ejecutar una reparación. Un código privado sólo es interpretable dentro del acuerdo que conserva su versión y su emisor.

Con RFC 9606, un resolver puede anunciar en RESINFO exterr qué códigos dice soportar. Si emite otro valor, el cliente puede refrescar la información y declarar inexacta una discrepancia persistente. La selección del resolver permanece local: capacidad publicada no equivale a confianza.

El mismo mecanismo expone decisiones distintas

BIND permite asociar códigos como Blocked, Censored, Filtered o Prohibited a respuestas modificadas por RPZ. La etiqueta explica una acción de política local, no el contenido original de la zona. Unbound separa la emisión general, Stale Answer y el reporte RFC 9567. PowerDNS activa errores ampliados de resolución en versiones actuales y documenta señales diagnósticas que no alteran validación ni AD.

La auditoría no puede limitarse a un booleano. Debe conocer códigos habilitados, texto, forwarding, caché, RPZ, múltiples opciones, transporte, presentación y fallback. Una actualización puede cambiar ese conjunto sin cambiar el RCODE visible.

EXTRA-TEXT no es un canal de órdenes

El texto libre puede revelar que un nombre está en una blocklist, describir configuración interna o incluir información privada. La RFC pide no poner datos que el observador no conocería, como números de cuenta. Un atacante también puede insertar caracteres de control, markup o instrucciones aparentes.

La interfaz escapa y limita el contenido; el log conserva el código estable separado de la frase; los bytes crudos quedan bajo acceso restringido. La aplicación nunca ejecuta URLs, comandos ni objetos estructurados extraídos de EXTRA-TEXT. Los mensajes localizados y seguros pertenecen al producto, no al emisor desconocido.

Un informe también consume DNS

RFC 9567 permite que el authoritative server anuncie Report-Channel. El resolver codifica QTYPE, QNAME y EDE en una consulta nueva hacia un agente. La retroalimentación puede revelar firmas caducadas que el operador no observa localmente.

Pero resolver el informe puede producir otro error. El protocolo exige un límite de gasto o profundidad. No existe autenticación mutua propia; TCP o DNS Cookies dificulta falsificar el origen y QNAME minimisation reduce exposición. El agente debe correlacionar el reporte con versiones de zona, firma, nodos y probes antes de automatizar cambios.

De vocabulario mínimo a decisión comprobada

Minimum Initial Specification es el formato pequeño: option 15, longitudes, índice y conservación del RCODE. Localized Future Decision deja a cada resolver y cliente decidir emisión, visualización y reacción. Voluntary Adoption sólo existe cuando software y usuarios conservan la semántica en ejecución.

Running-Code Primacy exige unir el código con hechos observables. Peer y transporte identificados, traza de validación, regla local, confirmación independiente, acción limitada y paquetes posteriores. Sin esa cadena, EDE aporta una pista valiosa, no una autoridad.

Fuentes