Resumen

  • La revisión 27 de Structured Error Data for Filtered DNS está en la cola del RFC Editor. Propone I-JSON dentro de EXTRA-TEXT para explicar un Extended DNS Error, pero aún no es un RFC numerado y conserva valores pendientes de asignación.
  • DoT, DoH o DoQ autenticados protegen el salto entre cliente y resolvedor. No acreditan por sí solos al autor de una política aguas arriba, su base legal o contractual, la corrección de la clasificación ni la acción final de la aplicación.

La claridad del formato puede ocultar una laguna de mandato

La escena inicial es un caso construido para el análisis, no un incidente real. Una respuesta ordenada produce confianza: tiene campos reconocibles, una categoría controlada y una explicación comprensible. Sin embargo, el hecho de que un resolvedor formule bien una afirmación no convierte esa afirmación en una decisión autorizada para toda persona y contexto.

El Datatracker identifica draft-ietf-dnsop-structured-dns-error-27, fechado el 30 de julio de 2026 y actualizado el 19 de agosto, como documento en RFC Ed Queue. Su destino previsto es Proposed Standard y todavía espera asignación de editor. No tiene número RFC. Las referencias pendientes a códigos IANA y al futuro RFC impiden hablar de valores finales o de compatibilidad universal.

RFC 8914 ya permite adjuntar Extended DNS Errors. Sus códigos pueden señalar que una respuesta fue bloqueada, filtrada, censurada o falsificada. El texto adicional se concibió como ayuda diagnóstica humana. La nueva propuesta permite que el cliente envíe una opción SDE EDNS vacía para indicar que entiende un objeto I-JSON en el campo EXTRA-TEXT.

El objeto separa contacto, justificación, suberror registrado, organización e idioma. Esa separación facilita localización, registro y soporte. No certifica el contenido. Un nombre de organización no demuestra identidad; una frase explicativa no demuestra causa; un número registrado no demuestra que el clasificador lo aplicó al nombre correcto.

Pedir datos estructurados no equivale a aceptar la regla

La opción SDE no transporta una política y tiene longitud cero. Declara capacidad del cliente, nada más. Una política local puede omitirla. Su presencia no es consentimiento para filtrar, para confiar en un proveedor o para iniciar contacto automáticamente.

El servidor puede seguir respondiendo con un conjunto vacío, NXDOMAIN o una dirección forjada. Cuando el cliente anunció SDE y aparece un EDE relacionado con filtrado, el servidor debería añadir detalle estructurado salvo configuración contraria. El borrador diferencia política del operador de red y política del operador DNS. También propone un código aún no asignado para un bloqueo comunicado por un servidor DNS aguas arriba.

Es una mejora porque evita atribuir toda decisión al último resolvedor. Aun así, las categorías no son poderes. «Política del operador de red» no muestra qué entidad la aprobó, qué contrato abarca al usuario, si una orden pública sigue vigente o si un proveedor de seguridad se equivocó. El protocolo describe el origen operativo declarado; no juzga su legitimidad.

Algo parecido ocurre con el suberror. El registro IANA permite que dos implementaciones entiendan el mismo entero. Esa interoperabilidad no convierte «malware» o «phishing» en una prueba forense. Para actuar hacen falta fecha, fuente de reputación, alcance, evidencia observada y reglas locales de respuesta.

El cifrado termina donde termina la conexión

El borrador prohíbe actuar sobre datos recibidos sin transporte cifrado. Un atacante en ruta podría cambiarlos. Incluso con cifrado, si el cliente no verifica la identidad del resolvedor debe ignorar contacto, justificación y organización, porque son textos capaces de influir en la conducta. El suberror enumerado puede recibir un tratamiento más limitado.

Un resolvedor autenticado mediante DoT, DoH o DoQ sí ofrece una propiedad fuerte: el cliente sabe con qué extremo habló y que la respuesta no fue alterada en esa conexión. Esa evidencia no debe minimizarse ni ampliarse. No prueba que el resolvedor aguas arriba originó el mismo mensaje, que un reenviador lo conservó o que la organización mencionada adoptó realmente la política.

EDE es salto a salto. Un reenviador puede transmitir la información, eliminar campos o crear un objeto nuevo. El proyecto deja esas opciones a la implementación y al operador. Por tanto, el último salto puede estar perfectamente autenticado mientras el tramo anterior carece de protección, o mientras el resolvedor final convierte un código breve en una explicación propia.

La diferencia es de procedencia, no de calidad criptográfica. Una organización que necesite reconstruir la autoridad debe conservar fuera del paquete la selección del resolvedor, el upstream configurado, el modo de reenvío, la versión de la política, la fuente del clasificador, la hora y el historial de rectificación.

Los reenviadores antiguos crean otro riesgo: pueden transportar EXTRA-TEXT inyectado sin comprenderlo. El borrador propone procesar EDE únicamente desde servidores DNS configurados de forma explícita o apoyarse en la información de resolvedor de RFC 9606. La confianza nace del vínculo operativo comprobado, no del aspecto estructurado del mensaje.

La ayuda al usuario también puede manipularlo

El contacto existe para corregir falsos positivos. Un resolvedor hostil podría usarlo para conducir al usuario hacia un atacante, pedirle información o venderle una falsa reparación. La justificación libre y el nombre de organización pueden aportar el tono persuasivo que falta a un simple código.

Por ello, la política del cliente decide qué mostrar. El contacto exige suficiente reputación del resolvedor según configuración administrativa o lista de confianza. La justificación no puede alimentar automatismos que cambien la política de seguridad o el protocolo DNS. El nombre de organización debe mostrarse como texto, sin enlaces, y solo cuando coincida con una identidad registrada de confianza o supere comprobaciones prudentes.

La propuesta deja fuera de alcance la construcción de la lista de organizaciones fiables. Es una frontera necesaria. El IETF puede definir la forma del mensaje; no puede decidir si una empresa, escuela, familia, ISP o autoridad pública tiene mandato sobre un usuario concreto. Quien soporte el daño de un bloqueo erróneo debe mantener y revisar esa relación.

El cliente tampoco debe abrir conexiones por una URI derivada del error. Limitar los esquemas reduce conexiones silenciosas, reflexión y trampas, pero no vuelve honrado al interlocutor. Una experiencia segura puede enseñar el resolvedor verificado, una descripción controlada y un canal de soporte preconfigurado, sin convertir cada campo libre en acción.

El TTL abre una nueva consulta, no cierra la disputa

Las listas de reputación cambian. El borrador acepta TTL breves, incluso de diez segundos, para absorber correcciones. Cuando los cambios son raros, treinta o sesenta segundos pueden equilibrar carga y flexibilidad. El vencimiento de una caché no garantiza que el clasificador upstream, todos los reenviadores y todos los clientes ya compartan el nuevo estado.

Conviene medir relojes distintos: caché DNS, actualización de la fuente, aprobación o revocación de política, gestión de reclamaciones y primera respuesta correcta observada. Un TTL de diez segundos sirve poco si la lista cambia cada hora o si el recurso humano tarda días.

Una rectificación demostrable enlaza nombre y tipo consultados, identidad del resolvedor, EDE y suberror, upstream visible, TTL positivos y negativos, versión de clasificación, recepción de la queja, responsable de la decisión y momento de convergencia. Una única respuesta favorable no prueba que el problema haya desaparecido en todas partes.

La privacidad requiere límites similares. La explicación puede revelar quién filtra, qué política usa y qué dominio intentó consultar la persona. El cliente no debe registrar ni transmitir esos datos a terceros sin conocimiento del usuario. Centralizar todos los errores en telemetría remota puede deshacer, después del resolvedor, la confidencialidad obtenida con DNS cifrado.

Explicar el bloqueo no decide la consecuencia

Después de autenticar el resolvedor y validar los campos, la aplicación aún puede mostrar un mensaje reducido, registrar localmente, derivar al soporte configurado, esperar al TTL, usar otra resolución cuando esté permitido, detener la operación o escalar a revisión. Un hogar, una red corporativa y un equipo crítico no comparten el mismo coste de error.

La capa común debe coordinar lo mínimo: señal de capacidad, campos, registros, orden de procesamiento, transporte y límites de seguridad. No debe convertir una declaración técnica en sentencia jurídica. Autor de política, proveedor de clasificación, operador, usuario y autoridad legal siguen siendo sujetos distintos.

El avance real no consiste en decorar el bloqueo. Consiste en poder preguntar quién eligió el resolvedor, quién adoptó la regla, quién aportó la clasificación, quién puede corregirla y quién decide el resultado local. Si esas respuestas se conservan, SDE mejora la rendición de cuentas. Si se pierden, la estructura solo presta apariencia de autoridad a una afirmación.

Sources