Resumen

  • DNS Filtering Transparency propone incluir en el error DNS un identificador de operador de base de datos y otro de incidente. Esa pareja dirige a una ficha, pero no autentica que la ficha corresponda al filtrado experimentado ni obliga al resolutor a revelar una referencia concreta.
  • La aplicación toma una decisión independiente: conserva su propia copia del registro, elige qué operadores admite o considera fiables y resuelve si muestra el enlace. La inscripción identifica una plantilla; no certifica la exactitud del incidente ni la legitimidad de la política.
  • Abrir la ficha puede revelar la dirección IP y el interés por un nombre sensible. El usuario debe conservar la última decisión, y la auditoría ha de separar emisión, presentación y acceso sin convertir la transparencia en vigilancia adicional.

La escena ideal es sencilla. Una consulta falla, el navegador explica que el resolutor la filtró y ofrece una página con más contexto. La persona deja de confundir una intervención de política con una avería. Puede comprender el motivo, informar de un falso positivo o buscar una vía de corrección.

Pero la frase visible no nace directamente del suceso. Es el producto de una pequeña cadena editorial. El resolutor decide qué referencias adjuntar. El cliente decide cuáles reconoce y está dispuesto a presentar. La persona decide si solicita la página que las referencias construyen. Cada actor controla un tramo distinto, y cada tramo puede cambiar lo que llega al siguiente.

El borrador de grupo de trabajo publicado el 1 de agosto de 2026 es valioso precisamente porque no oculta esa complejidad. El error opaco puede ganar contexto sin otorgar al servidor libertad para insertar cualquier URL o mensaje. El error sería interpretar esa mejora como una explicación única, completa y autenticada.

La referencia está estructurada, no demostrada

draft-ietf-dnsop-filtering-transparency-00 añade una lista fdbs a los datos estructurados de error. Cada elemento contiene db, que identifica al operador de una base sobre incidentes de filtrado, e id, que identifica una entrada. Si el resolutor incluye varias parejas, el texto exige que todas se refieran al mismo incidente subyacente.

El cliente no convierte esa pareja en una dirección por intuición. Busca db en una copia local del registro que el borrador pide crear a IANA, obtiene una plantilla URI de nivel 1 o 2 y la expande con id. La intermediación evita que un resolutor no fiable coloque libremente texto y enlaces en una interfaz que el usuario puede atribuir al navegador.

Esa protección no verifica el emparejamiento. La sección de seguridad reconoce que el mecanismo no autentica que el incidente vivido por la aplicación esté realmente asociado con la información mostrada. Quien controle el resolutor podría reutilizar una pareja que conduce a una ficha real y asociarla a una consulta diferente. La URL funcionaría y, aun así, la afirmación implícita sería falsa.

Por tanto, la existencia de la ficha solo demuestra que el recurso puede recuperarse mediante la plantilla. No acredita una orden, la competencia de quien la emitió, el alcance de la regla, su fecha, la jurisdicción aplicable ni que el filtro afectara exclusivamente al objetivo previsto. Tampoco resuelve si el contenido de la base es completo o ha sido corregido después.

Hay que conservar también el estatus de la especificación. La revisión 00 es un Internet-Draft activo de DNSOP que sustituyó a un trabajo individual anterior. No es un RFC y no declara todavía un estatus RFC previsto. Puede orientar experimentación y debate; no debe presentarse como una obligación ya acordada por el IETF.

Primera decisión: qué cuenta el resolutor

El borrador no obliga a transmitir información específica. El resolutor elige qué proveedores de bases admite y aplica los mecanismos que considere oportunos para decidir cuándo y en qué casos incluye una referencia. La lista recibida es, por diseño, una selección.

Puede haber una sola ficha, varias o ninguna. El operador quizá solo mapea algunas clases de política; quizá una base no cubre su jurisdicción; quizá una obligación impide exponer más detalle; quizá el sistema interno no ha vinculado aún el evento con una entrada pública. Enumerar estas posibilidades no acusa a nadie. Sirve para impedir que una ausencia se transforme en un hecho positivo que los datos no sostienen.

Sin fdbs, lo único comprobado es que la respuesta observada no entregó una referencia utilizable. No se demuestra que no hubiera filtrado, expediente, orden o posibilidad de reparación. Incluso con una referencia emitida, ciertas aplicaciones no verán los detalles porque su arquitectura anfitriona no les da acceso a la respuesta DNS completa.

La custodia del resolutor debería registrar la hora, la consulta y respuesta bajo una política de minimización, el contexto de autenticación del servicio DNS si existe, el código EDE, las parejas emitidas, la regla que las seleccionó y si se conocían alternativas no incluidas. La información sensible puede tener acceso restringido y plazos cortos; la decisión de selección no puede desaparecer si luego se exige rendición de cuentas.

Segunda decisión: qué voz distribuye la aplicación

El cliente funciona como un distribuidor. Mantiene una copia local del registro y decide qué operadores de bases reconoce o en cuáles confía. El borrador dice que esa evaluación puede depender del resolutor que produjo el error, del operador de la base y de la configuración local. También admite que las aplicaciones podrán mostrar o no mostrar la información.

Así, dos dispositivos pueden recibir la misma respuesta y generar experiencias distintas. Uno reconoce db, expande la plantilla y ofrece una referencia; otro desconoce el identificador. Uno confía en ese operador cuando el error procede de un resolutor configurado; otro lo rechaza en una red encontrada. Un sistema operativo entrega los campos estructurados al navegador; otro los retiene. Ninguna captura del resultado final descubre por sí sola cuál de estas decisiones ocurrió.

El tiempo añade otra bifurcación. El contacto de una entrada puede cambiar la plantilla en cualquier momento, y el borrador advierte que las aplicaciones pueden tardar mucho en actualizar sus copias. La dirección construida durante un incidente depende de la versión local de entonces. Consultar el registro actual meses después puede producir otro destino y borrar la evidencia de lo que realmente se ofreció.

Además, registro no equivale a sello de calidad. El borrador propone una política de primero en llegar, primero en ser atendido, aunque IANA podría rechazar solicitudes engañosas o espurias. RFC 8126 explica que ese procedimiento no realiza una revisión sustantiva normal: comprueba principalmente forma y ausencia de duplicados. El registro asigna un identificador y un controlador de cambio; la aplicación sigue siendo responsable de decidir si distribuye la voz que hay detrás.

El recibo de aplicación debe fijar la fecha o huella de su copia, la plantilla expandida, las versiones de la lista admitida y la política de confianza, las entradas aceptadas y descartadas, el motivo clasificable y el tipo de mensaje mostrado. Sin ese rastro, los equipos atribuirán al resolutor silencios creados por el cliente o culparán a la política de confianza de un enlace roto por una plantilla obsoleta.

Tercera decisión: buscar contexto sin delatar la búsqueda

La página explicativa no llega dentro del DNS. Para leerla, la aplicación inicia otra conexión. El operador de la base puede recibir la IP del usuario y aprender que desde ella se intentó resolver un nombre sujeto a filtrado. En asuntos delicados, la consulta de la explicación puede ser tan reveladora como la consulta original.

Por eso el borrador prohíbe la recuperación automática, salvo que exista un mecanismo de preservación de privacidad: sin un proxy u otra protección, debe haber una acción explícita del usuario. También alerta sobre identificadores únicos que permitirían a un resolutor y a un operador de base coordinados correlacionar actividad, incluso si formalmente parecen dos servicios.

La interfaz puede anunciar la existencia de contexto sin descargarlo. Debe distinguir entre ruta directa y protegida, aclarar el destinatario y hacer que el gesto preceda a la conexión. La evidencia de cumplimiento no exige archivar quién visitó qué dominio. Basta con conservar que la descarga automática estaba desactivada, que hubo una acción, qué clase de ruta se empleó y si la operación terminó.

Esta minimización es importante. Un sistema concebido para explicar una intervención no debe acabar creando un inventario más detallado de las personas que intentaron entenderla. La transparencia pierde su sentido si el precio de solicitar motivos es una huella nueva, invisible e indefinida.

Tres capas técnicas, tres límites de autoridad

El borrador depende de Structured Error Data for Filtered DNS, que vuelve procesables algunos campos antes destinados a texto humano. Esa especificación, a su vez, dice que los datos no deben considerarse automáticamente fiables, mostrarse ni influir en decisiones de seguridad sin validación adecuada. El transporte DNS cifrado protege frente a observadores pasivos, pero no garantiza la veracidad de lo dicho por el extremo.

RFC 8914 ya había separado el código de error ampliado de la respuesta DNS básica: la explicación añade contexto, no cambia el resultado. La nueva referencia añade profundidad, pero tampoco hereda una autoridad que su capa inferior no tenía. Estructura, cifrado, registro y disponibilidad son propiedades distintas de verdad, legitimidad y exhaustividad.

RFC 7754 ayuda a identificar la cadena anterior al protocolo. Quien establece una política de bloqueo puede no ser quien la aplica. Entre una ley, una norma administrativa, una política del operador y una regla técnica hay traducciones capaces de introducir consecuencias no previstas. El aviso facilita corregir errores; no juzga por sí mismo la legalidad o la ética de la intervención.

Un recibo para la cadena de divulgación

Daniel Kade propone tres módulos enlazados. El primero conserva la observación del resolutor, la relación autenticada o su ausencia, el EDE, las parejas emitidas, la política de selección y las omisiones conocidas. El segundo conserva la instantánea del registro, la plantilla usada, la configuración de operadores admitidos, la decisión de confianza y la presentación resultante. El tercero conserva si se ofreció la consulta, si la acción explícita ocurrió antes de la red, si se usó protección y cuál fue el desenlace.

Las incertidumbres no se rellenan. Si la identidad del resolutor no está autenticada, queda marcada como tal. Si no se conoce por qué una pareja fue omitida, no se inventa un motivo. Si la ficha cambia, su versión actual no reemplaza la que estaba disponible. Una orden o política independiente se adjunta como evidencia separada y con su propia procedencia; jamás se deduce de db e id.

El recibo no aprueba el filtrado. Hace auditable el camino de la explicación. Permite localizar dónde desapareció una referencia, por qué una aplicación no la mostró y qué exposición habría creado abrirla. Esa separación evita que un aviso limpio se convierta en una autoridad ficticia construida a partir de tres decisiones que nadie quiso reconocer como tales.

Fuentes