Registres del resolutor DNS versus registres de connexió VPN: què guarda cadascun
Un resolutor enregistra els noms que se li va demanar de respondre; una VPN enregistra esdeveniments del túnel des de la seva pròpia implementació. Una política de retenció no cobreix l'altra.
Un registre del resolutor DNS i un registre de connexió VPN són tots dos registres de xarxa, tots dos útils i no intercanviables. El resolutor rep els noms que se li va demanar de respondre. El punt final de la VPN gestiona les connexions de túnel i enregistra el que la seva implementació va triar enregistrar-ne. Poden ser al mateix edifici, estar operats pel mateix equip i quedar coberts pel mateix avís de privadesa, i tot i així descriuen esdeveniments diferents amb identificadors diferents i retenció diferent. Llegir-ne un com si fos l'altre és com les investigacions es desvien.
Dos registres, dos esdeveniments
Una entrada del resolutor respon una pregunta sobre nomenament: aquest client va demanar aquest nom en aquest moment, i la resposta va ser aquesta. Una entrada de la VPN respon una pregunta sobre connectivitat: aquest peer va establir o va perdre un túnel, va rebre aquesta adreça i va transferir aproximadament aquesta quantitat de dades abans de desaparèixer. Cap dels dos no és un registre del que l'usuari va fer dins d'una sessió HTTPS, i cap no substitueix l'altre.
La distinció té una conseqüència pràctica per a les promeses. Una afirmació que un proveïdor de VPN no enregistra l'activitat del túnel no diu res sobre el resolutor que lliura, i la política de retenció d'un resolutor no diu res sobre qui es va connectar al túnel. Cada afirmació pertany al seu operador i al seu sistema.
Seguiu la consulta abans de llegir qualsevol dels dos registres
Una consulta arriba a un resolutor només si el camí realment el pregunta. Una aplicació pot usar el resolutor del sistema operatiu, executar el seu propi client DNS xifrat o llegir una resposta en memòria cau i no enviar mai res. Per tant, un registre de resolutor que no mostra res no és evidència que un nom no s'hagi usat mai; és evidència que aquest resolutor no va ser preguntat.
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pagerAquesta darrera ordre llegeix el diari propi del resolutor local, que no és el mateix que el registre del servidor superior. Si les vostres consultes surten per DNS over HTTPS cap a un proveïdor, l'stub local pot no mostrar res mentre el proveïdor té el registre complet, i el proveïdor és un operador diferent amb una política diferent.
Què pot i què no pot mostrar cada registre
| Record | Typically shows | Does not show |
|---|---|---|
| Resolver log | Queried name, client address, time, response | Which page was fetched, or what the tunnel did |
| VPN connection log | Peer identity, assigned address, connect and disconnect times, volume | Which name the application asked for |
| Application or proxy log | Requests, status codes, sometimes full URLs | Resolved addresses for every dependency |
Unir-los és on és la feina de veritat, i unir-los no sempre és possible. Un resolutor que enregistra adreces de clients es pot comparar amb una VPN que assigna adreces d'un pool conegut, i aquesta comparació produeix un vincle plausible entre un nom consultat i un túnel, que continua sent un vincle entre dos registres i no un registre d'una persona.
El DNS xifrat canvia el transport, no la visibilitat al punt final. El resolutor encara rep la pregunta que respon, tal com RFC 8484 deixa clar, i la retenció en aquest resolutor és una decisió de política i no una propietat del protocol.
On el DNS dividit i les memòries cau confonen la història
Múltiples resolutors són normals. Un disseny de DNS dividit envia els noms interns a un servidor intern i tota la resta a un de públic, així que una sola investigació pot implicar dos registres que mai no es van pensar per combinar i dos paràmetres de retenció que mai no es van pensar per comparar. Veure consultes en tots dos és evidència que el disseny funciona, no evidència d'una fuita.
Les memòries cau tallen en l'altre sentit. Un nom popular pot ser respost des de la memòria cau durant hores, així que el registre del resolutor mostra la primera consulta i després res, mentre l'aplicació de l'usuari continua resolent el mateix nom sense problemes. L'absència d'entrades després d'un moment determinat no vol dir que ningú no hagi usat el nom després d'aquell moment.
El trànsit de fons és la tercera distorsió. Un telèfon que resol un nom de telemetria en arrencar, un navegador que resol un domini de suggeriment de cerca i un actualitzador que es connecta cada hora apareixen tots al registre del resolutor al costat del nom que realment us importa. El volum en aquest registre no és atenció, i comptar consultes no és comptar visites. Un registre de resolutor és un registre de preguntes, i les preguntes són barates de generar.
Feu les preguntes sobre retenció per separat
Per a cada sistema, feu tres preguntes: qui recull, què es recull i quant de temps es guarda. Després pregunteu qui el pot llegir i amb quin procés. La discussió de l'RFC 8484 sobre DNS over HTTPS és un bon recordatori que el transport xifrat no elimina el punt final, i la documentació pròpia de l'operador és l'única afirmació fiable sobre què guarda aquest punt final.
Quan es fa una afirmació sobre privadesa sobre “la VPN”, dividiu-la en components abans d'acceptar-la: l'operador del túnel, el resolutor que el túnel lliura, qualsevol resolutor superior al qual arribin aquestes consultes i les aplicacions del dispositiu. Cadascun té la seva resposta, i una afirmació exacta per a un es repeteix habitualment com si cobrís tots quatre.
Per a la resolució de problemes, feu servir la mateixa divisió. Pregunteu quina aplicació va fer la consulta i quin resolutor la va respondre, i després mireu el registre que realment posseeix aquell esdeveniment. Endevinar des de l'altre registre estalvia un minut i costa una tarda.