DNS atrisinātāja žurnāli un VPN savienojuma žurnāli: ko katrs glabā

DNS atrisinātāja žurnāls un VPN savienojuma žurnāls abi ir tīkla ieraksti, abi noderīgi un nav savstarpēji aizstājami. Atrisinātājs saņem vārdus, uz kuriem tam tika lūgts atbildēt. VPN galapunkts apstrādā tuneļa savienojumus un ieraksta to, ko tā implementācija izvēlējās par tiem ierakstīt. Tie var atrasties vienā ēkā, tos var pārvaldīt viena komanda un uz tiem var attiekties viens un tas pats privātuma paziņojums, un tomēr tie apraksta atšķirīgus notikumus ar atšķirīgiem identifikatoriem un atšķirīgu glabāšanu. Viena lasīšana tā, it kā tas būtu otrs, ir ceļš, kā izmeklēšanas aiziet nepareizā virzienā.

Divi žurnāli, divi notikumi

Atrisinātāja ieraksts atbild uz jautājumu par nosaukšanu: šis klients šajā laikā pieprasīja šo vārdu, un atbilde bija šī. VPN ieraksts atbild uz jautājumu par savienojamību: šis partneris izveidoja vai zaudēja tuneli, tam tika piešķirta šī adrese, un tas pārsūtīja aptuveni tik daudz datu, pirms pazuda. Neviens no tiem nav ieraksts par to, ko lietotājs darīja HTTPS sesijas ietvaros, un neviens neaizstāj otru.

Šai atšķirībai ir praktiskas sekas solījumiem. Apgalvojums, ka VPN pakalpojumu sniedzējs neieraksta tuneļa darbību, neko nepasaka par atrisinātāju, ko tas nodrošina, un atrisinātāja glabāšanas politika neko nepasaka par to, kas pievienojās tunelim. Katrs apgalvojums pieder savam operatoram un savai sistēmai.

Izsekojiet vaicājumam, pirms lasāt jebkuru no žurnāliem

Vaicājums atrisinātāju sasniedz tikai tad, ja ceļš tiešām to jautā. Lietojumprogramma var izmantot operētājsistēmas atrisinātāju, darbināt savu šifrēto DNS klientu vai nolasīt kešatmiņā saglabātu atbildi un nekad neko nesūtīt. Tāpēc atrisinātāja žurnāls, kas neko nerāda, nav pierādījums tam, ka vārds nekad nav lietots; tas ir pierādījums tam, ka šim atrisinātājam netika jautāts.

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

Pēdējā komanda nolasa paša vietējā atrisinātāja žurnālu, kas nav tas pats, kas augšupējā servera žurnāls. Ja jūsu vaicājumi iziet caur DNS over HTTPS pie pakalpojumu sniedzēja, vietējais stubs var neko nerādīt, kamēr pakalpojumu sniedzējam ir pilnīgs ieraksts, un pakalpojumu sniedzējs ir cits operators ar citu politiku.

Ko katrs ieraksts var un ko nevar parādīt

To savienošana ir īstais darbs, un savienošana ne vienmēr ir iespējama. Atrisinātāju, kas ieraksta klientu adreses, var salīdzināt ar VPN, kas piešķir adreses no zināma kopuma, un šis salīdzinājums rada ticamu saiti starp vaicāto vārdu un tuneli, kas paliek saite starp diviem ierakstiem, nevis ieraksts par personu.

Šifrētais DNS maina transportu, nevis redzamību galapunktā. Atrisinātājs joprojām saņem jautājumu, uz kuru atbild, kā RFC 8484 skaidri parāda, un glabāšana šajā atrisinātājā ir politikas lēmums, nevis protokola īpašība.

Kur sadalītais DNS un kešatmiņas sajauc stāstu

Vairāki atrisinātāji ir norma. Sadalītā DNS dizains sūta iekšējos vārdus uz iekšēju serveri un visu pārējo uz publisku, tāpēc viena izmeklēšana var ietvert divus žurnālus, kas nekad nav bijuši paredzēti apvienošanai, un divus glabāšanas iestatījumus, kas nekad nav bijuši paredzēti salīdzināšanai. Vaicājumu redzēšana abos ir pierādījums tam, ka dizains strādā, nevis noplūdes pierādījums.

Kešatmiņas griež pretējā virzienā. Populāram vārdam var atbildēt no kešatmiņas stundām ilgi, tāpēc atrisinātāja ieraksts rāda pirmo vaicājumu un pēc tam neko, kamēr lietotāja lietojumprogramma turpina priecīgi atrisināt to pašu vārdu. Ierakstu neesamība pēc noteikta laika nenozīmē, ka neviens pēc šī laika vārdu nelietoja.

Fona trafiks ir trešais izkropļojums. Tālrunis, kas sāknēšanas laikā atrisina telemetrijas vārdu, pārlūks, kas atrisina meklēšanas ieteikuma domēnu, un atjauninātājs, kas reizi stundā pārbauda, visi parādās atrisinātāja žurnālā līdzās vārdam, kas jums tiešām ir svarīgs. Apjoms šajā žurnālā nav uzmanība, un vaicājumu skaitīšana nav apmeklējumu skaitīšana. Atrisinātāja žurnāls ir jautājumu ieraksts, un jautājumus ir lēti radīt.

Uzdodiet glabāšanas jautājumus atsevišķi

Katrai sistēmai uzdodiet trīs jautājumus: kas vāc, ko vāc un cik ilgi tas tiek glabāts. Pēc tam jautājiet, kas to var lasīt un kādā procesā. RFC 8484 diskusija par DNS over HTTPS ir labs atgādinājums, ka šifrēts transports nenoņem galapunktu, un paša operatora dokumentācija ir vienīgais uzticamais apgalvojums par to, ko šis galapunkts glabā.

Kad tiek izteikts apgalvojums par privātumu saistībā ar „VPN”, sadaliet to komponentos, pirms to pieņemat: tuneļa operators, tuneļa nodrošinātais atrisinātājs, jebkurš augšupējais atrisinātājs, ko sasniedz šie vaicājumi, un ierīcē esošās lietojumprogrammas. Katram ir sava atbilde, un apgalvojums, kas precīzs vienam, tiek regulāri atkārtots tā, it kā tas aptvertu visus četrus.

Problēmu novēršanai izmantojiet to pašu sadalījumu. Jautājiet, kura lietojumprogramma veica vaicājumu un kurš atrisinātājs uz to atbildēja, pēc tam apskatiet žurnālu, kuram tiešām pieder šis notikums. Minēšana no otra žurnāla ietaupa minūti un izmaksā pēcpusdienu.