Jurnalele resolverului DNS și jurnalele conexiunilor VPN: ce păstrează fiecare

Un jurnal al resolverului DNS și un jurnal al conexiunilor VPN sunt ambele înregistrări de rețea, ambele utile și nu sunt interschimbabile. Resolverul primește numele pentru care i s-a cerut să răspundă. Punctul final al VPN tratează conexiunile de tunel și înregistrează ce a ales implementarea sa să înregistreze despre ele. Pot fi în aceeași clădire, pot fi operate de aceeași echipă și pot intra sub aceeași notificare de confidențialitate, și totuși descriu evenimente diferite cu identificatori diferiți și păstrare diferită. Citirea unuia ca și cum ar fi celălalt este felul în care anchetele o iau greșit.

Două jurnale, două evenimente

O intrare a resolverului răspunde la o întrebare despre denumire: acest client a cerut acest nume în acest moment, iar răspunsul a fost acesta. O intrare a VPN răspunde la o întrebare despre conectivitate: acest peer a stabilit sau a pierdut un tunel, i-a fost atribuită această adresă și a transferat aproximativ atât de multe date înainte de a dispărea. Niciuna nu este o înregistrare a ceea ce a făcut utilizatorul într-o sesiune HTTPS și niciuna nu o înlocuiește pe cealaltă.

Distincția are o consecință practică pentru promisiuni. Afirmația că un furnizor de VPN nu înregistrează activitatea tunelului nu spune nimic despre resolverul pe care îl oferă, iar politica de păstrare a unui resolver nu spune nimic despre cine s-a conectat la tunel. Fiecare afirmație aparține propriului operator și propriului sistem.

Urmați interogarea înainte de a citi oricare dintre jurnale

O interogare ajunge la un resolver doar dacă calea chiar îl întreabă. O aplicație poate folosi resolverul sistemului de operare, poate rula propriul client DNS criptat sau poate citi un răspuns din cache și nu trimite niciodată nimic. Așadar, un jurnal al resolverului care nu arată nimic nu este dovada că un nume nu a fost niciodată folosit; este dovada că acest resolver nu a fost întrebat.

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

Acea ultimă comandă citește jurnalul propriu al resolverului local, ceea ce nu este același lucru cu jurnalul serverului din amonte. Dacă interogările dumneavoastră ies prin DNS over HTTPS către un furnizor, stubul local poate să nu arate nimic în timp ce furnizorul are înregistrarea completă, iar furnizorul este un alt operator cu altă politică.

Ce poate și ce nu poate arăta fiecare înregistrare

A le corela este munca reală, iar corelarea nu este întotdeauna posibilă. Un resolver care înregistrează adresele clienților poate fi comparat cu un VPN care atribuie adrese dintr-un pool cunoscut, iar comparația produce o legătură plauzibilă între un nume interogat și un tunel, care rămâne o legătură între două înregistrări, nu o înregistrare a unei persoane.

DNS-ul criptat schimbă transportul, nu vizibilitatea la punctul final. Resolverul primește în continuare întrebarea la care răspunde, după cum RFC 8484 arată clar, iar păstrarea la acel resolver este o decizie de politică și nu o proprietate a protocolului.

Unde DNS-ul divizat și cache-urile încurcă povestea

Mai multe resolvere sunt normale. Un design cu DNS divizat trimite numele interne către un server intern și tot restul către unul public, așa că o singură anchetă poate implica două jurnale care nu au fost niciodată gândite să fie combinate și două setări de păstrare care nu au fost niciodată gândite să fie comparate. A vedea interogări în ambele este dovada că designul funcționează, nu dovada unei scurgeri.

Cache-urile taie în cealaltă direcție. Un nume popular poate fi servit din cache ore întregi, așa că înregistrarea resolverului arată prima interogare și apoi nimic, în timp ce aplicația utilizatorului continuă să rezolve fericit același nume. Absența intrărilor după un anumit moment nu înseamnă că nimeni nu a folosit numele după acel moment.

Traficul de fundal este a treia distorsiune. Un telefon care rezolvă un nume de telemetrie la pornire, un browser care rezolvă un domeniu de sugestie de căutare și un actualizator care se conectează la fiecare oră apar toate într-un jurnal al resolverului lângă numele care vă interesează cu adevărat. Volumul din acel jurnal nu este atenție, iar numărarea interogărilor nu este numărarea vizitelor. Un jurnal al resolverului este o înregistrare a întrebărilor, iar întrebările sunt ieftin de generat.

Puneți întrebările despre păstrare separat

Pentru fiecare sistem, puneți trei întrebări: cine colectează, ce se colectează și cât timp este păstrat. Apoi întrebați cine îl poate citi și în ce proces. Discuția din RFC 8484 despre DNS over HTTPS este o bună reamintire că transportul criptat nu elimină punctul final, iar documentația proprie a unui operator este singura afirmație de încredere despre ce păstrează acel punct final.

Când se face o afirmație despre confidențialitate despre „VPN”, împărțiți-o în componente înainte de a o accepta: operatorul tunelului, resolverul pe care tunelul îl oferă, orice resolver din amonte la care ajung aceste interogări și aplicațiile de pe dispozitiv. Fiecare are propriul răspuns, iar o afirmație exactă pentru unul este repetată în mod obișnuit ca și cum le-ar acoperi pe toate patru.

Pentru depanare, folosiți aceeași împărțire. Întrebați ce aplicație a făcut interogarea și ce resolver a răspuns, apoi uitați-vă la jurnalul care deține cu adevărat acel eveniment. Ghicitul din celălalt jurnal economisește un minut și costă o după-amiază.