Resumen

  • La propuesta no deja que el resolvedor inyecte una URL libre: entrega un identificador de base y otro de incidente, y la aplicación los resuelve con una copia local del registro y su propia política de confianza.
  • Esa copia tiene edad y procedencia; una plantilla actualizada no llega de inmediato a todos los clientes, por lo que registro vigente, versión instalada y destino realmente mostrado son estados distintos.

El operador de una base cambió su dominio y actualizó la plantilla registrada. El registro público ya apuntaba al nuevo sitio. Sin embargo, una aplicación que llevaba tres meses sin actualizar siguió expandiendo cada incidente hacia la dirección anterior.

El identificador era correcto. La ruta usada por el lector ya no lo era.

draft-ietf-dnsop-filtering-transparency-00 propone una manera limitada de explicar intervenciones que, vistas desde una aplicación, se parecen a una avería. La limitación es su defensa principal: el resolvedor no escribe el mensaje final ni entrega una URL arbitraria. Proporciona referencias abstractas; la aplicación conserva el control de la ruta y de la confianza.

La revisión 00 está fechada el 1 de agosto de 2026 y vence el 2 de febrero de 2027. Es un Internet-Draft activo del grupo DNSOP con intención Standards Track. No es una RFC, un registro IANA operativo, una política de navegador ni una medición de despliegue. Además depende del borrador de errores DNS estructurados, por lo que fdbs sigue siendo una pieza propuesta, no un contrato final.

El registro se copia, no se consulta para cada incidente

Cada entrada combina db, identificador del operador de una base de filtrado, e id, identificador de un incidente. Varias entradas pueden viajar en una lista fdbs si se refieren al mismo suceso subyacente.

Para convertir la pareja en una dirección, la aplicación busca db en su copia del DNS Filtering Database Registry. La fila aporta nombre, contacto y una plantilla URI de nivel 1 o 2. La aplicación inserta id y obtiene una dirección que podría ofrecer al usuario.

El texto exige mantener una copia local y prohíbe consultar IANA en cada uso. La decisión reduce dependencia y evita revelar a un servicio central cada error. También convierte la actualización en un proceso distribuido.

Un contacto puede cambiar la plantilla. El borrador reconoce que las aplicaciones tardarán en incorporar el cambio. Por eso “estaba en IANA” no reproduce la experiencia del lector. Hace falta saber qué versión tenía el cliente, cuándo la recibió y qué cadena exacta expandió.

La cadena de custodia incluye instantánea del registro, política de confianza y resultado de la plantilla. Sin esos tres elementos, una investigación posterior puede reconstruir un destino distinto al que realmente se presentó.

El resolvedor no debe escoger una URL libre

Los resolvedores pueden ser configurados automáticamente por una red desconocida. Una respuesta DNS tampoco ofrece por sí sola autenticidad frente a todas las amenazas. Permitir enlaces o texto sin restricción daría a un punto de acceso hostil una vía directa hacia la interfaz del navegador.

La indirection por registro limita la superficie. El atacante necesita reutilizar un operador conocido y una pareja que produzca una URL válida. La aplicación puede reconocer sólo algunos operadores y descartar los demás.

Esa mejora no vuelve verdadera la afirmación. El resolvedor puede asociar una consulta con un incidente que no ocurrió. La página puede existir y describir otro caso. La expansión correcta prueba sintaxis y disponibilidad, no causalidad.

El sistema debería registrar “afirmado por el resolvedor”, “resuelto por esta instantánea”, “aceptado por política” y “cargado con éxito” como estados diferentes. Ninguno equivale a “orden legal autenticada”.

Primero en llegar no significa digno de confianza

El registro propuesto usaría first come, first served, aunque IANA podría rechazar solicitudes engañosas o espurias. Esa política coordina nombres y reduce colisiones. No evalúa la metodología de la base.

Una fila no garantiza independencia, cobertura, corrección, conservación prudente ni competencia jurídica. Tampoco obliga a una aplicación a mostrarla. El borrador deja el juicio en el consumidor, que puede considerar el operador, el resolvedor y la configuración local.

Confundir registro con acreditación crea una transferencia de autoridad no prevista. IANA administra la correspondencia. La aplicación decide confianza. El usuario decide si sigue el enlace. La base publica una afirmación. Cada actor posee una promesa distinta.

Una página disponible no autentica el bloqueo

La especificación advierte que no hay mecanismo para probar que el incidente experimentado corresponde a la información presentada. Un atacante que controle el resolvedor puede afirmar un filtrado inexistente.

Debe encontrar una pareja válida que llegue a una página real. Eso impone fricción, pero un incidente auténtico puede usarse como coartada para otra consulta. Un registro profesional puede ser citado fuera de contexto.

La respuesta HTTP sólo demuestra que el servidor atendió una ruta. La existencia del texto sólo demuestra que alguien lo publicó. Para probar el incidente haría falta una unión verificable entre consulta, política aplicada, actor responsable y registro, unión que el borrador no define.

El lenguaje de producto tiene que respetar el límite. “Más contexto comunicado por su resolvedor” es defendible. “Motivo verificado del bloqueo” no lo es.

Abrir la explicación vuelve a exponer el interés

La consulta de la URL puede revelar al operador de la base la dirección IP del usuario y el dominio filtrado que intentó resolver. En ciertos lugares, esa combinación tiene consecuencias personales.

Un observador de red también puede inferir el incidente por el destino, el momento o el identificador. Confiar en la base no cifra mágicamente el camino. Un proxy de privacidad puede separar la dirección del usuario, aunque introduce otro custodio y otros registros.

Sin proxy, la aplicación no debe cargar automáticamente la página antes de una acción explícita. La prohibición incluye comportamientos que los equipos suelen considerar auxiliares: vista previa, escáner, comprobación de reputación, preconexión y expansión de metadatos.

Mostrar un botón y cargar por detrás no preserva la decisión. La telemetría necesita distinguir enlace construido, enlace visible, clic, ruta directa o proxy, redirección y respuesta.

Un identificador único puede enlazar dos mundos

El id puede ser común a muchas observaciones o particular de una petición. Si el resolvedor y la base cooperan, un token único permite reconocer qué referencia enviada por DNS regresó luego mediante HTTP.

La misma entidad puede operar ambos servicios. El usuario verá una explicación, mientras la infraestructura relaciona su búsqueda con su visita. La utilidad pública del registro no elimina ese canal.

La aplicación debe observar cardinalidad, patrón y duración de los identificadores. La política de confianza necesita preguntas concretas: ¿se emite un ID por causa, por dominio, por red, por cliente o por consulta? ¿Cuánto dura? ¿Qué se conserva cuando se visita?

El proxy oculta parte de la fuente, pero no el token. Si conserva registros detallados, la correlación cambia de lugar. La privacidad debe abarcar todo el trayecto.

El host puede borrar el detalle

No todas las aplicaciones reciben las opciones de una respuesta DNS. El resolvedor puede enviar fdbs; el sistema operativo puede entregar sólo “nombre no resuelto”; el navegador no tendrá datos que presentar.

Por eso el mecanismo no es fiable en toda arquitectura. La cadena real pasa por emisión, recepción, exposición del host, análisis, búsqueda en el registro, decisión de confianza, presentación, acción y recuperación.

La ausencia de visitas a la base no prueba ausencia de mensajes. La emisión no prueba que alguien fue informado. Una función compilada en el navegador no prueba que la API del sistema le entregue el campo.

Cada transición necesita numerador y denominador propios. Una cifra final sin pérdidas intermedias recompensa la ilusión de cobertura.

Varias bases pueden discrepar

La lista permite que un mismo incidente aparezca en más de una base, aumentando la probabilidad de que una aplicación reconozca alguna. Pero fecha, fundamento, actor o alcance pueden no coincidir.

El requisito de “mismo incidente” viene de la afirmación del resolvedor. No establece una reconciliación independiente. Una mayoría de páginas tampoco demuestra el hecho.

Una interfaz responsable mantiene la procedencia y muestra la divergencia, o aplica una prioridad local explícita. No debería combinar textos hasta ocultar quién afirmó cada punto.

La transparencia termina donde empieza la certeza inventada

La propuesta reparte el poder: el resolvedor cita, el registro orienta, la aplicación selecciona y el usuario decide revelar la consulta posterior. Su seguridad depende de no volver a juntar esos papeles en una implementación cómoda.

Una copia local sin versión, una lista de confianza sin dueño, una precarga invisible o una etiqueta de “verificado” pueden deshacer esa separación. El registro debe seguir siendo delgado y reproducible.

El objetivo no es probar automáticamente la legalidad del filtrado. Es impedir que una intervención parezca sólo un fallo técnico, sin convertir la explicación en una URL inyectada, un certificado implícito o un rastreador obligatorio.

Fuentes