Resumen

  • La autenticación y el cifrado prueban propiedades del tramo entre cliente y resolutor, pero no demuestran qué hace el operador con la consulta una vez descifrada.
  • La declaración RPS del RFC 8932 permite comparar compromisos; para verificar una promesa hacen falta comprobantes distintos y fechados del transporte, el procesamiento, el almacenamiento y acceso, y la salida de datos.

En una cafetería, un teléfono deja de enviar consultas DNS legibles por la red inalámbrica y establece una conexión autenticada con un servicio conocido. El operador del punto de acceso ya no puede elaborar con la misma facilidad una lista de dominios. Un atacante situado en ese tramo pierde una vía simple de observación y alteración. Es una mejora concreta.

Al llegar al resolutor, sin embargo, la consulta tiene que quedar disponible para ser procesada. El servicio consulta la caché, valida o busca una respuesta y, si es necesario, pregunta a servidores situados más arriba. El operador puede ver el nombre y ciertos identificadores del cliente; también determina si los guarda, los combina con otros datos, los comparte o altera la contestación. El cifrado ha cambiado quién observa durante el trayecto, no ha borrado al destinatario de confianza.

Esa frontera articula el RFC 8932, Recommendations for DNS Privacy Service Operators. Publicado en octubre de 2020 como BCP 232, tiene cuatro autores: Sara Dickinson, Benno Overeinder, Roland van Rijswijk-Deij y Allison Mankin. El perfil de Dickinson en IETF registra ocho RFC, entre ellos este documento y el RFC 9250 sobre DNS mediante QUIC, y su papel como presidenta del Privacy Enhancements and Assessments Research Group. RIPE Labs la identifica como cofundadora de Sinodun IT. Son pruebas de una trayectoria y una contribución colectiva, no de autoría exclusiva ni de control sobre los despliegues ajenos.

El RFC ofrece recomendaciones para operar servicios DNS privados e introduce la Recursive operator Privacy Statement, la RPS. La idea no consiste en imponer una política idéntica a todos. Consiste en que los operadores publiquen, con un orden comparable, tanto sus compromisos como sus prácticas presentes. El lector puede entonces separar lo que se afirma de lo que se puede medir. La RPS no es asesoramiento jurídico ni un sello automático de cumplimiento.

El primer comprobante cubre el transporte. Debe poder responder a qué extremo se conectó el cliente, qué nombre autenticó, qué protocolo usó, si el certificado fue válido, qué versión TLS o QUIC negoció, si aplicó relleno y qué ocurrió cuando el servicio falló. El RFC 8310 trata los perfiles de uso de DNS sobre TLS, el RFC 8484 define DNS sobre HTTPS y el RFC 9250 incorpora conexiones QUIC dedicadas. Los tres protegen una relación con el resolutor. Ninguno demuestra que los datos desaparezcan después.

Tampoco conviene mezclar esa prueba con DNSSEC. El RFC 8932 declara que el cifrado de transporte y DNSSEC son independientes y resuelven problemas diferentes. Si el cliente no valida DNSSEC por sí mismo, una conexión autenticada no demuestra que el resolutor haya validado los registros. Puede limitarse a confiar en el bit AD que recibe. El certificado del servidor prueba la identidad del interlocutor de transporte; no certifica la procedencia criptográfica de cada respuesta DNS.

El segundo comprobante pertenece al procesamiento. ¿Qué modo de validación actuó? ¿Respondió la caché? ¿Se aplicó una lista de bloqueo, una excepción o una transformación? ¿El servicio enlazó sesiones mediante una dirección IP, la reanudación TLS, una cabecera HTTP, una huella del cliente o un patrón de consultas? El RFC 9076 advierte, además, de que el tráfico cifrado de entrada puede correlacionarse con preguntas no cifradas que salen del resolutor.

Elegir siempre el mismo servicio puede aclarar a quién se confían las consultas en redes diferentes. También puede facilitar que ese servicio reconozca al mismo usuario mientras cambia de red. Ambas afirmaciones pueden ser verdaderas. La confidencialidad frente a intermediarios y la limitación de correlación por parte del operador son controles distintos, con responsables y evidencias distintas.

El filtrado también es procesamiento. El esquema RPS pide que se declare si las respuestas se filtran o modifican por seguridad informática, por una orden jurídica vinculante, por una política voluntaria para reducir riesgo legal, por razones comerciales o por cualquier otro motivo. Asimismo pide describir la procedencia y gestión de las listas. El canal puede ser confidencial y la respuesta puede estar intervenida: la expresión «DNS seguro» no resuelve esa ambigüedad.

El tercer comprobante se refiere al almacenamiento y al acceso. El RFC 8932 recomienda reducir la conservación al mínimo o evitarla por completo. Cuando haya que retener datos, aconseja cifrarlos y, cuando sea posible, agregarlos, seudonimizarlos o anonimizarlos. Los registros no deberían durar más de lo necesario para operar y atender obligaciones aplicables, y su acceso debería limitarse al personal que lo necesita.

Un compromiso escrito no demuestra su ejecución. La frase «borramos a los siete días» se contrasta con reglas de ciclo de vida y resultados de borrado. Una matriz de permisos se contrasta con el registro real de accesos. El cifrado del disco no prueba que nunca se exportó una copia. Y la seudonimización no debe presentarse como anonimato: un sustituto estable aún permite enlazar actividad durante meses y, si aparece el mapa o el método, puede volver a revelar una identidad.

El cuarto comprobante mira hacia fuera. Un resolutor recursivo interroga otros sistemas para completar su trabajo. El RFC 8932 recomienda minimizar el QNAME, de modo que cada nivel conozca solo la porción del nombre que necesita; el RFC 9156 actualiza ese comportamiento. También aconseja prescindir de EDNS Client Subnet o, cuando sea imprescindible, enviar el prefijo más corto viable y publicar la política real.

Una medición externa puede detectar que una consulta concreta fue minimizada y no llevaba ECS. Su valor reside precisamente en su límite: tiene hora, punto de observación y caso de prueba. No demuestra que todas las rutas, destinos y configuraciones sean idénticos. Mucho menos permite observar qué ocurrió con una copia almacenada o si después se entregó a un tercero.

Por eso la RPS enumera preguntas incómodamente específicas. ¿Se tratan las direcciones IP como datos personales? ¿Qué se recopila, conserva, comparte, vende o alquila? ¿Qué excepciones hay? ¿Qué afiliados, socios o fuentes de financiación intervienen? ¿Se combina el historial DNS con otros datos? ¿Cómo se filtran respuestas? La parte dedicada a la práctica añade los transportes disponibles, la autenticación, la actuación hacia los servidores de autoridad, las desviaciones de la política y los canales de asistencia.

Una declaración madura convierte cada respuesta en una dirección hacia la evidencia. La minimización del QNAME remite a configuración y sondas; la retención, a temporizadores y borrados; el acceso, a roles y eventos auditados; una transferencia, a su destinatario, finalidad, campos, condición y caducidad. Un informe de transparencia o una auditoría independiente puede ampliar la observación, siempre que conserve fechas, muestras y exclusiones.

Ningún documento elimina por sí solo la distancia entre política y práctica. Una auditoría ve un periodo; una sonda ve un recorrido; un informe ve aquello a lo que accedió su autor; la RPS puede quedarse anticuada. La respuesta sensata no es declarar imposible la privacidad, sino exigir el testigo adecuado para cada afirmación y evitar que una prueba se extienda más allá de lo observado.

El mérito duradero del marco elaborado por Dickinson y sus coautores es trasladar el debate desde el símbolo de cifrado hasta las decisiones que siguen vivas detrás de él. La pregunta profesional deja de ser solo «¿va cifrada la consulta?» y pasa a ser «¿quién puede decidir sobre ella al llegar, qué rastro conserva esa decisión y cuándo caduca la prueba?».

Fuentes