Registros del resolutor DNS frente a registros de conexión VPN: qué guarda cada uno

Un registro del resolutor DNS y un registro de conexión VPN son ambos registros de red, ambos útiles y no intercambiables. El resolutor recibe los nombres que se le pidió responder. El punto de salida de la VPN gestiona las conexiones de túnel y registra lo que su implementación decidió registrar sobre ellas. Pueden estar en el mismo edificio, ser operados por el mismo equipo y quedar cubiertos por el mismo aviso de privacidad, y aun así describen eventos distintos con identificadores distintos y retención distinta. Leer uno como si fuera el otro es la forma en que las investigaciones se tuercen.

Dos registros, dos eventos

Una entrada del resolutor responde a una pregunta sobre nombres: este cliente pidió este nombre en este momento, y la respuesta fue esta. Una entrada de la VPN responde a una pregunta sobre conectividad: este par estableció o perdió un túnel, recibió esta dirección y transfirió aproximadamente esta cantidad de datos antes de desaparecer. Ninguno de los dos es un registro de lo que el usuario hizo dentro de una sesión HTTPS, y ninguno sustituye al otro.

La distinción tiene una consecuencia práctica para las promesas. Una afirmación de que un proveedor de VPN no registra la actividad del túnel no dice nada sobre el resolutor que entrega, y la política de retención de un resolutor no dice nada sobre quién se conectó al túnel. Cada afirmación pertenece a su propio operador y a su propio sistema.

Siga la consulta antes de leer cualquiera de los dos registros

Una consulta llega a un resolutor solo si la ruta realmente se lo pregunta. Una aplicación puede usar el resolutor del sistema operativo, ejecutar su propio cliente DNS cifrado o leer una respuesta en caché y no enviar nunca nada. Así que un registro del resolutor que no muestra nada no es prueba de que un nombre nunca se usara; es prueba de que a este resolutor no se le preguntó.

resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager

Ese último comando lee el diario propio del resolutor local, que no es lo mismo que el registro del servidor ascendente. Si sus consultas salen mediante DNS over HTTPS hacia un proveedor, el stub local puede no mostrar nada mientras el proveedor tiene el registro completo, y el proveedor es otro operador con otra política.

Qué puede y qué no puede mostrar cada registro

Unirlos es donde está el trabajo real, y unirlos no siempre es posible. Un resolutor que registra direcciones de clientes puede compararse con una VPN que asigna direcciones de un grupo conocido, y esa comparación produce un vínculo verosímil entre un nombre consultado y un túnel, que sigue siendo un vínculo entre dos registros y no un registro de una persona.

El DNS cifrado cambia el transporte, no la visibilidad en el punto de salida. El resolutor sigue recibiendo la pregunta que responde, como RFC 8484 deja claro, y la retención en ese resolutor es una decisión de política y no una propiedad del protocolo.

Donde el DNS dividido y las cachés confunden la historia

Varios resolutores son normales. Un diseño de DNS dividido envía los nombres internos a un servidor interno y todo lo demás a uno público, así que una sola investigación puede implicar dos registros que nunca se pensaron para combinarse y dos ajustes de retención que nunca se pensaron para compararse. Ver consultas en ambos es prueba de que el diseño funciona, no prueba de una fuga.

Las cachés cortan en la otra dirección. Un nombre popular puede responderse desde la caché durante horas, así que el registro del resolutor muestra la primera consulta y luego nada, mientras la aplicación del usuario sigue resolviendo el mismo nombre tan contenta. La ausencia de entradas después de cierto momento no significa que nadie usara el nombre después de ese momento.

El tráfico de fondo es la tercera distorsión. Un teléfono que resuelve un nombre de telemetría al arrancar, un navegador que resuelve un dominio de sugerencia de búsqueda y un actualizador que se conecta cada hora aparecen todos en un registro del resolutor junto al nombre que de verdad le importa. El volumen en ese registro no es atención, y contar consultas no es contar visitas. Un registro del resolutor es un registro de preguntas, y las preguntas son baratas de generar.

Haga las preguntas sobre retención por separado

Para cada sistema, haga tres preguntas: quién recoge, qué se recoge y cuánto tiempo se conserva. Luego pregunte quién puede leerlo y con qué proceso. La discusión del RFC 8484 sobre DNS over HTTPS es un buen recordatorio de que el transporte cifrado no elimina el punto de salida, y la documentación propia del operador es la única afirmación fiable sobre lo que ese punto de salida conserva.

Cuando se hace una afirmación sobre privacidad acerca de «la VPN», divídala en componentes antes de aceptarla: el operador del túnel, el resolutor que entrega el túnel, cualquier resolutor ascendente al que lleguen esas consultas y las aplicaciones del dispositivo. Cada uno tiene su propia respuesta, y una afirmación exacta para uno se repite habitualmente como si cubriera los cuatro.

Para resolver problemas, use la misma división. Pregunte qué aplicación hizo la consulta y qué resolutor la respondió, y luego mire el registro que realmente es dueño de ese evento. Adivinar desde el otro registro ahorra un minuto y cuesta una tarde.