Resumen

  • Los RCODE clásicos comunican el desenlace común, no la causa detallada. RFC 8914 usó la opción EDNS 15 para transportar un INFO-CODE registrado y un EXTRA-TEXT opcional destinado a personas.
  • EDE puede acompañar SERVFAIL, NXDOMAIN, REFUSED e incluso NOERROR; también puede repetirse varias veces. La aplicación debe seguir procesando el RCODE según su especificación y no convertir el diagnóstico en una orden paralela.
  • El contexto tiene una cadena de custodia imperfecta: un reenviador puede omitirlo o recrearlo, el límite UDP puede expulsarlo antes que los datos principales, el texto puede filtrar información y un canal sin protección permite falsificarlo.

La pantalla del usuario ha borrado casi toda la historia. Si el resolver obtuvo datos que debían validar y no pudo construir la cadena DNSSEC, buscar una respuesta en un resolver no validador no repara nada. Si ninguna autoridad respondió, una nueva ruta o un nuevo intento sí puede producir evidencia distinta. Ambas situaciones pueden terminar en SERVFAIL.

La ambigüedad importa porque el siguiente paso puede fortalecer o debilitar el sistema. La solución histórica no consistió en hacer que el RCODE supiera todo, sino en permitir que una explicación viajara a su lado sin adquirir su autoridad.

Un resultado pequeño ocultaba ramas operativas grandes

RFC 1035 fijó un repertorio reducido: respuesta correcta, formato inválido, fallo del servidor, nombre inexistente, operación no admitida y rechazo. Ese vocabulario estable permite interoperar con servidores cuya arquitectura interna es desconocida.

SERVFAIL no diferencia un servidor todavía no preparado, una autoridad inalcanzable, un error guardado, una validación DNSSEC fallida o datos de zona inválidos. REFUSED no distingue falta de autoridad, cliente no autorizado y política de bloqueo. La misma superficie puede corresponder a decisiones de reparación incompatibles.

El límite no vuelve inútil al RCODE. Su función es declarar el resultado que todos deben procesar. La causa necesita otro espacio, ampliable sin convertir cada incidente interno en una nueva semántica básica.

EDNS abrió un bolsillo para el diagnóstico

RFC 6891 creó el pseudo-RR OPT y un espacio de opciones. OPT forma parte del mensaje, pero no de los datos normales de una zona. Puede llevar capacidades y metadatos sin atribuirlos al propietario de un nombre.

RFC 8914 asignó en 2020 la opción 15 a Extended DNS Error. Después del encabezado EDNS aparece un INFO-CODE de 16 bits. Los octetos restantes pueden contener EXTRA-TEXT en UTF-8.

El número funciona como índice del registro IANA. El texto sirve a una persona y no debe analizarse como protocolo. Puede tener longitud cero; no se presupone terminación nula y su frontera procede de la longitud de la opción.

Una respuesta puede contener EDE con cualquier RCODE cuando la consulta incluyó OPT. Puede llevar varias opciones y el receptor debe tolerarlas, aunque no deba actuar sobre todas. Esta multiplicidad evita forzar una cadena causal a un único valor.

La norma central es que EDE no modifica el procesamiento del RCODE. SERVFAIL más DNSSEC Bogus continúa siendo un fallo. NOERROR más Stale Answer entrega datos, pero no borra que su TTL venció. El contexto orienta el diagnóstico; no vota otra vez el desenlace.

La palabra Bogus no demostraba mala fe

RFC 4035 llama Bogus al RRset para el que debería existir una cadena de confianza, pero la validación no puede establecerla por una firma fallida o por datos que deberían estar presentes y faltan. Puede haber ataque, mala configuración o corrupción.

Indeterminate significa que el resolver no consigue el material necesario para determinar si el RRset tendría que estar firmado. No es la misma afirmación: una prueba esperada fracasó en un caso; en el otro no se puede decidir qué prueba era exigible.

EDE dio números distintos a ambos estados y también a algoritmo DNSKEY no admitido, tipo de resumen DS no admitido, firma expirada o todavía no válida, DNSKEY o RRSIG ausente, bit de clave de zona apagado y NSEC faltante.

La precisión acota la investigación, no adjudica culpa. Padre, hijo, registrador, reloj, software o camino pueden intervenir. El código registra la conclusión local del resolver. Para atribuir responsabilidad hace falta conservar fuentes y realizar nuevas pruebas.

Un NOERROR podía reconocer que el dato era viejo

Cuando el resolver no logra refrescar una caché, puede decidir que un dato recién vencido ofrece mejor continuidad que un fallo. RFC 8767 delimita esa práctica. EDE 3 marca una respuesta positiva antigua y EDE 19 un NXDOMAIN antiguo.

No existe contradicción entre NOERROR y Stale Answer. El RCODE clasifica lo que se entrega; EDE describe su estado temporal. Servir la copia no rejuvenece el TTL ni prueba una confirmación reciente de la autoridad.

EDE 4, Forged Answer, se reserva para una respuesta que una política alteró y que aún se entrega. Si la política impide responder, Blocked, Censored y Filtered separan política interna del operador, imposición externa y filtrado solicitado por el cliente. Prohibited puede explicar una negativa a un cliente no autorizado.

Las etiquetas muestran quién afirma ejercer control, pero no autentican una orden externa, una lista de amenazas o el consentimiento del cliente. Su valor depende de la procedencia preservada.

La memoria del resolver también retenía fallos

Repetir una resolución completa para cada consulta puede multiplicar el trabajo durante una avería. RFC 9520 establece un tratamiento acotado para almacenar fallos de resolución.

EDE 13, Cached Error, informa de que el SERVFAIL actual se leyó de esa memoria. No transforma el error en dato autoritativo ni garantiza que la causa original siga activa. Sí evita confundir una lectura repetida con una observación nueva.

Miles de clientes pueden recibir la misma entrada de caché. Contarlos como miles de fallos independientes exagera la evidencia. Una comprobación útil espera el vencimiento, consulta otro resolver controlado o prueba directamente la ruta de autoridad.

El reenviador podía convertirse en narrador

El stub suele consultar a un resolver cercano. Este puede reenviar a un servicio corporativo o público. La EDE que llega al cliente parece emitida por el último salto, aunque otro sistema haya observado la causa.

RFC 8914 permite al reenviador no transmitirla, pasar su sentido o crear otra opción. Si conserva una causa de aguas arriba, debería atribuir su fuente en EXTRA-TEXT. Sin esa marca, una afirmación ajena queda presentada como propia.

Varias EDE pueden conservar capas: fallo de validación arriba, error guardado localmente y política aplicada a la salida. Pero una lista sin autor no es una cronología. El texto puede añadir el origen, aunque siga siendo lenguaje humano y no una prueba autenticada.

La explicación era prescindible cuando faltaba espacio

Un EXTRA-TEXT largo puede superar el tamaño UDP anunciado. RFC 8914 indica que el servidor debería eliminar las EDE antes que otros datos y activar el bit de truncamiento cuando las retira.

La prioridad define la relación contractual: la explicación ayuda, pero respuesta y pruebas esenciales valen más. La ausencia de EDE no demuestra que no hubiera diagnóstico; pudo perderse por tamaño, política de reenvío o falta de implementación.

La observabilidad debe registrar generación, recepción, reemplazo, supresión y truncamiento. Añadir prosa sin límite puede provocar transporte TCP o hacer que la propia explicación sea lo primero que desaparece.

Una frase concreta seguía sin estar autenticada

«Firma vencida» parece más fiable que un fallo genérico. La especificidad psicológica no añade criptografía.

RFC 8914 considera la EDE no autenticada salvo que la transacción DNS esté protegida o autenticada. Un adversario que inserta una explicación quizá también pueda cambiar el RCODE o un registro A. Por eso el contexto debe permanecer diagnóstico y no modificar el procesamiento.

El texto introduce además fuga de información. Puede revelar cuentas, servidores internos, políticas o presencia en una lista de bloqueo. La explicación correcta no publica todo; entrega lo mínimo necesario para elegir la prueba siguiente y el actor competente.

El registro de parámetros DNS de IANA enumera la opción 15 y códigos añadidos después del conjunto inicial. Demuestra asignaciones coordinadas, no cuota de despliegue, emisión correcta, fidelidad del reenvío, protección ni visualización al usuario.

Extended DNS Error convirtió una causa oculta en contexto transportable sin crear una segunda verdad. El RCODE conserva la decisión común. EDE conserva una pista sobre su origen. Esa subordinación permite reparar con mayor precisión sin cambiar integridad por una apariencia de disponibilidad.