DNS sprendiklio žurnalai ir VPN ryšio žurnalai: ką kiekvienas saugo

DNS sprendiklio žurnalas ir VPN ryšio žurnalas abu yra tinklo įrašai, abu naudingi ir nepakeičiami. Sprendiklis gauna vardus, kurių buvo paprašytas atsakyti. VPN galinis taškas tvarko tunelio ryšius ir įrašo tai, ką jo įgyvendinimas pasirinko apie juos įrašyti. Jie gali būti tame pačiame pastate, juos gali valdyti ta pati komanda ir jiems gali būti taikomas tas pats privatumo pranešimas, tačiau jie aprašo skirtingus įvykius su skirtingais identifikatoriais ir skirtingu saugojimu. Vieno skaitymas lyg jis būtų kitas – tai kelias, kuriuo tyrimai pakrypsta ne ta linkme.

Dveji žurnalai, du įvykiai

Sprendiklio įrašas atsako į klausimą apie pavadinimų suteikimą: šis klientas šiuo metu paprašė šio vardo, ir atsakymas buvo toks. VPN įrašas atsako į klausimą apie junglumą: šis partneris užmezgė arba prarado tunelį, jam buvo priskirtas šis adresas ir jis perdavė maždaug tiek duomenų, kol dingo. Nė vienas nėra įrašas apie tai, ką naudotojas veikė HTTPS sesijos viduje, ir nė vienas nepakeičia kito.

Šis skirtumas turi praktinių pasekmių pažadams. Teiginys, kad VPN tiekėjas neregistruoja tunelio veiklos, nieko nesako apie jo teikiamą sprendiklį, o sprendiklio saugojimo politika nieko nesako apie tai, kas prisijungė prie tunelio. Kiekvienas teiginys priklauso savo operatoriui ir savo sistemai.

Sekite užklausą prieš skaitydami bet kurį žurnalą

Užklausa sprendiklį pasiekia tik tada, kai kelias iš tikrųjų jo klausia. Programa gali naudoti operacinės sistemos sprendiklį, paleisti savo šifruotą DNS klientą arba perskaityti podėlyje esantį atsakymą ir nieko nesiųsti. Taigi sprendiklio žurnalas, kuriame nieko nematyti, nėra įrodymas, kad vardas niekada nebuvo naudotas; tai įrodymas, kad šio sprendiklio nebuvo klausta.

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

Paskutinė komanda skaito paties vietinio sprendiklio žurnalą, o tai nėra tas pats kaip viršutinio serverio žurnalas. Jei jūsų užklausos išeina per DNS over HTTPS pas tiekėją, vietinis stub gali nieko nerodyti, nors tiekėjas turi visą įrašą, o tiekėjas yra kitas operatorius su kita politika.

Ką kiekvienas įrašas gali ir ko negali parodyti

Jų sujungimas ir yra tikrasis darbas, o sujungti juos ne visada įmanoma. Sprendiklį, kuris registruoja klientų adresus, galima palyginti su VPN, kuris priskiria adresus iš žinomo telkinio, ir šis palyginimas sukuria tikėtiną ryšį tarp užklausto vardo ir tunelio, kuris išlieka ryšiu tarp dviejų įrašų, o ne asmens įrašu.

Šifruotas DNS keičia transportą, o ne matomumą galiniame taške. Sprendiklis vis dar gauna klausimą, į kurį atsako, kaip RFC 8484 aiškiai parodo, o saugojimas tame sprendiklyje yra politikos sprendimas, o ne protokolo savybė.

Kur padalytas DNS ir podėliai supainioja istoriją

Keli sprendikliai yra norma. Padalyto DNS dizainas siunčia vidinius vardus į vidinį serverį, o visa kita – į viešą, todėl vienas tyrimas gali apimti du žurnalus, kurie niekada nebuvo skirti sujungti, ir du saugojimo nustatymus, kurie niekada nebuvo skirti palyginti. Užklausų matymas abiejuose yra įrodymas, kad dizainas veikia, o ne nuotėkio įrodymas.

Podėliai pjauna priešinga kryptimi. Populiarus vardas gali būti atsakomas iš podėlio valandų valandas, todėl sprendiklio įrašas rodo pirmąją užklausą ir tada nieko, o naudotojo programa toliau linksmai sprendžia tą patį vardą. Įrašų nebuvimas po tam tikro laiko nereiškia, kad po to laiko niekas vardo nenaudojo.

Foninis srautas yra trečiasis iškraipymas. Telefonas, kuris įjungimo metu išsprendžia telemetrijos vardą, naršyklė, kuri išsprendžia paieškos pasiūlymo domeną, ir atnaujinimo programa, kuri prisijungia kas valandą, visi pasirodo sprendiklio žurnale šalia vardo, kuris jums iš tikrųjų rūpi. Apimtis tame žurnale nėra dėmesys, o užklausų skaičiavimas nėra apsilankymų skaičiavimas. Sprendiklio žurnalas yra klausimų įrašas, o klausimus kurti pigu.

Saugojimo klausimus užduokite atskirai

Kiekvienai sistemai užduokite tris klausimus: kas renka, kas renkama ir kiek laiko tai saugoma. Tada paklauskite, kas gali tai skaityti ir kokia tvarka. RFC 8484 diskusija apie DNS over HTTPS yra geras priminimas, kad šifruotas transportas nepašalina galinio taško, o paties operatoriaus dokumentacija yra vienintelis patikimas teiginys apie tai, ką tas galinis taškas saugo.

Kai teiginys apie privatumą sakomas apie „VPN“, suskaidykite jį į komponentus prieš priimdami: tunelio operatorius, tunelio teikiamas sprendiklis, bet koks viršutinis sprendiklis, kurį pasiekia šios užklausos, ir įrenginyje esančios programos. Kiekvienas turi savo atsakymą, o teiginys, tikslus vienam, įprastai kartojamas taip, lyg apimtų visus keturis.

Trikčių šalinimui naudokite tą patį padalijimą. Paklauskite, kuri programa atliko užklausą ir kuris sprendiklis į ją atsakė, tada pažiūrėkite į žurnalą, kuris iš tikrųjų valdo tą įvykį. Spėliojimas iš kito žurnalo sutaupo minutę ir kainuoja popietę.