Protokoly DNS resolvera verzus protokoly VPN pripojenia: čo ktorý obsahuje

Protokol DNS resolvera a protokol VPN pripojenia sú oba sieťové záznamy, oba užitočné a nie sú zameniteľné. Resolver prijíma názvy, na ktoré bol požiadaný odpovedať. Koncový bod VPN spracúva tunelové pripojenia a zaznamenáva to, čo sa jeho implementácia rozhodla o nich zaznamenať. Môžu sídliť v tej istej budove, prevádzkovať ich ten istý tím a vzťahovať sa na ne to isté oznámenie o ochrane súkromia, a napriek tomu opisujú odlišné udalosti s odlišnými identifikátormi a odlišným uchovávaním. Čítať jeden, akoby to bol druhý, je spôsob, akým sa vyšetrovania zvrtnú.

Dva protokoly, dve udalosti

Záznam v resolveri odpovedá na otázku o pomenovaní: tento klient si v tomto čase vyžiadal tento názov a odpoveďou bolo toto. Záznam vo VPN odpovedá na otázku o konektivite: tento partner nadviazal alebo stratil tunel, bola mu pridelená táto adresa a preniesol približne toľko dát, kým zmizol. Ani jeden nie je záznamom toho, čo používateľ robil v rámci relácie HTTPS, a ani jeden nenahrádza druhý.

Rozdiel má praktický dôsledok pre sľuby. Tvrdenie, že poskytovateľ VPN nezaznamenáva aktivitu tunela, nehovorí nič o resolveri, ktorý poskytuje, a zásada uchovávania resolvera nehovorí nič o tom, kto sa k tunelu pripojil. Každé tvrdenie patrí svojmu operátorovi a svojmu systému.

Pred čítaním ktoréhokoľvek protokolu sledujte dopyt

Dopyt sa k resolveru dostane len vtedy, keď sa ho cesta skutočne spýta. Aplikácia môže použiť resolver operačného systému, spustiť vlastného šifrovaného DNS klienta alebo prečítať odpoveď z pamäte a nikdy nič neposlať. Protokol resolvera, ktorý nič neukazuje, teda nie je dôkazom, že sa názov nikdy nepoužil; je dôkazom, že sa tento resolver nespýtali.

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

Posledný príkaz číta vlastný žurnál miestneho resolvera, čo nie je to isté ako protokol nadradeného servera. Ak vaše dopyty odchádzajú cez DNS over HTTPS k poskytovateľovi, miestny stub nemusí ukazovať nič, zatiaľ čo poskytovateľ má kompletný záznam, a poskytovateľ je iný operátor s inou zásadou.

Čo ktorý záznam môže a nemôže ukázať

Spojiť ich je tá skutočná práca a spojiť ich nie je vždy možné. Resolver, ktorý zaznamenáva adresy klientov, možno porovnať s VPN, ktorá prideľuje adresy zo známeho fondu, a toto porovnanie vytvára vierohodné spojenie medzi dopytovaným názvom a tunelom, ktoré zostáva spojením medzi dvoma záznamami, nie záznamom o človeku.

Šifrované DNS mení prenos, nie viditeľnosť v koncovom bode. Resolver stále dostáva otázku, na ktorú odpovedá, ako RFC 8484 jasne ukazuje, a uchovávanie v tomto resolveri je rozhodnutím zásady, nie vlastnosťou protokolu.

Kde rozdelené DNS a pamäte zamotávajú príbeh

Viac resolverov je normálne. Návrh s rozdeleným DNS posiela interné názvy na interný server a všetko ostatné na verejný, takže jedno vyšetrovanie môže zahŕňať dva protokoly, ktoré sa nikdy nemali kombinovať, a dve nastavenia uchovávania, ktoré sa nikdy nemali porovnávať. Vidieť dopyty v oboch je dôkaz, že návrh funguje, nie dôkaz úniku.

Pamäte režú opačným smerom. Populárny názov môže byť z pamäte zodpovedaný celé hodiny, takže záznam resolvera ukazuje prvý dopyt a potom nič, zatiaľ čo aplikácia používateľa ďalej v pokoji prekladá ten istý názov. Neprítomnosť záznamov po určitom čase neznamená, že názov po tomto čase nikto nepoužil.

Prevádzka na pozadí je tretie skreslenie. Telefón, ktorý pri štarte prekladá názov telemetrie, prehliadač, ktorý prekladá doménu návrhu vyhľadávania, a aktualizátor, ktorý sa každú hodinu hlási, sa všetky objavujú v protokole resolvera vedľa názvu, na ktorom vám skutočne záleží. Objem v tomto protokole nie je pozornosť a počítanie dopytov nie je počítanie návštev. Protokol resolvera je záznam otázok a otázky sa dajú generovať lacno.

Pýtajte sa na uchovávanie oddelene

Pre každý systém položte tri otázky: kto zbiera, čo sa zbiera a ako dlho sa to uchováva. Potom sa spýtajte, kto to môže čítať a v akom procese. Diskusia k RFC 8484 o DNS over HTTPS je dobrou pripomienkou, že šifrovaný prenos neodstraňuje koncový bod, a vlastná dokumentácia operátora je jediné spoľahlivé tvrdenie o tom, čo tento koncový bod uchováva.

Keď sa tvrdenie o súkromí týka „VPN“, rozdeľte ho pred prijatím na časti: operátor tunela, resolver, ktorý tunel poskytuje, akýkoľvek nadradený resolver, ku ktorému sa tieto dopyty dostanú, a aplikácie v zariadení. Každá má svoju odpoveď a tvrdenie presné pre jednu sa bežne opakuje, akoby pokrývalo všetky štyri.

Pri riešení problémov použite rovnaké rozdelenie. Spýtajte sa, ktorá aplikácia dopyt vytvorila a ktorý resolver naň odpovedal, a potom sa pozrite do protokolu, ktorý tej udalosti skutočne patrí. Hádanie z druhého protokolu ušetrí minútu a stojí popoludnie.