Log del resolver DNS e log delle connessioni VPN: cosa contiene ciascuno

Un log del resolver DNS e un log delle connessioni VPN sono entrambi registrazioni di rete, entrambi utili e non intercambiabili. Il resolver riceve i nomi a cui gli è stato chiesto di rispondere. L'endpoint della VPN gestisce le connessioni del tunnel e registra ciò che la sua implementazione ha scelto di registrare al riguardo. Possono trovarsi nello stesso edificio, essere gestiti dallo stesso team e rientrare nello stesso avviso sulla privacy, e descrivono comunque eventi diversi con identificatori diversi e conservazione diversa. Leggere l'uno come se fosse l'altro è il modo in cui le indagini prendono una piega sbagliata.

Due log, due eventi

Una voce del resolver risponde a una domanda sulla denominazione: questo client ha chiesto questo nome in questo momento, e la risposta era questa. Una voce della VPN risponde a una domanda sulla connettività: questo peer ha stabilito o perso un tunnel, ha ricevuto questo indirizzo e ha trasferito all'incirca questa quantità di dati prima di andarsene. Nessuno dei due è una registrazione di ciò che l'utente ha fatto dentro una sessione HTTPS, e nessuno sostituisce l'altro.

La distinzione ha una conseguenza pratica per le promesse. L'affermazione che un fornitore VPN non registra l'attività del tunnel non dice nulla sul resolver che distribuisce, e la politica di conservazione di un resolver non dice nulla su chi si è connesso al tunnel. Ogni affermazione appartiene al proprio operatore e al proprio sistema.

Segui la query prima di leggere l'uno o l'altro log

Una query raggiunge un resolver solo se il percorso gliela chiede davvero. Un'applicazione può usare il resolver del sistema operativo, eseguire il proprio client DNS cifrato, oppure leggere una risposta in cache e non inviare mai nulla. Quindi un log del resolver che non mostra nulla non è la prova che un nome non sia mai stato usato; è la prova che questo resolver non è stato interrogato.

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

Quest'ultimo comando legge il giornale del resolver locale stesso, che non è la stessa cosa del log del server a monte. Se le tue query escono tramite DNS over HTTPS verso un fornitore, lo stub locale può non mostrare nulla mentre il fornitore ha la registrazione completa, e il fornitore è un altro operatore con un'altra politica.

Cosa può e cosa non può mostrare ciascuna registrazione

Collegarle è il vero lavoro, e collegarle non è sempre possibile. Un resolver che registra gli indirizzi dei client può essere confrontato con una VPN che assegna indirizzi da un pool noto, e quel confronto produce un legame plausibile tra un nome interrogato e un tunnel, che resta un legame tra due registrazioni e non la registrazione di una persona.

Il DNS cifrato cambia il trasporto, non la visibilità all'endpoint. Il resolver riceve ancora la domanda a cui risponde, come RFC 8484 chiarisce, e la conservazione presso quel resolver è una decisione di politica e non una proprietà del protocollo.

Dove il DNS diviso e le cache confondono la storia

Più resolver sono normali. Un progetto con DNS diviso invia i nomi interni a un server interno e tutto il resto a uno pubblico, così una singola indagine può coinvolgere due log che non erano mai stati pensati per essere combinati e due impostazioni di conservazione che non erano mai state pensate per essere confrontate. Vedere query in entrambi è prova che il progetto funziona, non prova di una fuga.

Le cache tagliano nella direzione opposta. Un nome popolare può essere risolto dalla cache per ore, così la registrazione del resolver mostra la prima query e poi nulla, mentre l'applicazione dell'utente continua a risolvere lo stesso nome senza problemi. L'assenza di voci dopo un certo momento non significa che nessuno abbia usato il nome dopo quel momento.

Il traffico di fondo è la terza distorsione. Un telefono che risolve un nome di telemetria all'avvio, un browser che risolve un dominio di suggerimento di ricerca e un programma di aggiornamento che si collega ogni ora compaiono tutti in un log del resolver accanto al nome che ti interessa davvero. Il volume in quel log non è attenzione, e contare le query non è contare le visite. Un log del resolver è una registrazione di domande, e le domande sono economiche da generare.

Poni le domande sulla conservazione separatamente

Per ogni sistema, poni tre domande: chi raccoglie, cosa viene raccolto e per quanto tempo viene conservato. Poi chiedi chi può leggerlo e con quale processo. La discussione del RFC 8484 su DNS over HTTPS è un buon promemoria del fatto che il trasporto cifrato non elimina l'endpoint, e la documentazione dell'operatore stesso è l'unica affermazione affidabile su ciò che quell'endpoint conserva.

Quando si fa un'affermazione sulla privacy riguardo alla «VPN», scomponila prima di accettarla: l'operatore del tunnel, il resolver che il tunnel fornisce, qualsiasi resolver a monte raggiunto da quelle query e le applicazioni sul dispositivo. Ognuno ha la propria risposta, e un'affermazione esatta per uno viene ripetuta abitualmente come se coprisse tutti e quattro.

Per la risoluzione dei problemi, usa la stessa divisione. Chiedi quale applicazione ha fatto la query e quale resolver ha risposto, poi guarda il log che possiede davvero quell'evento. Indovinare dall'altro log fa risparmiare un minuto e costa un pomeriggio.