Protokoly DNS resolveru versus protokoly VPN připojení: co který obsahuje

Protokol DNS resolveru a protokol VPN připojení jsou oba síťové záznamy, oba užitečné a nejsou zaměnitelné. Resolver přijímá názvy, na které byl požádán odpovědět. Koncový bod VPN zpracovává tunelová připojení a zaznamenává, co se jeho implementace rozhodla o nich zaznamenat. Mohou sídlit ve stejné budově, provozovat je stejný tým a vztahovat se na ně stejné oznámení o ochraně soukromí, a přesto popisují různé události s různými identifikátory a různou dobou uchovávání. Číst jeden, jako by to byl druhý, je způsob, jak se vyšetřování zvrtne.

Dva protokoly, dvě události

Záznam v resolveru odpovídá na otázku o pojmenování: tento klient si v této době vyžádal tento název a odpovědí bylo toto. Záznam ve VPN odpovídá na otázku o konektivitě: tento protějšek navázal nebo ztratil tunel, byla mu přidělena tato adresa a přenesl přibližně tolik dat, než zmizel. Ani jeden není záznamem toho, co uživatel dělal v HTTPS relaci, a ani jeden nenahrazuje druhý.

Rozdíl má praktický důsledek pro sliby. Tvrzení, že poskytovatel VPN nezaznamenává aktivitu tunelu, neříká nic o resolveru, který poskytuje, a zásada uchovávání resolveru neříká nic o tom, kdo se k tunelu připojil. Každé tvrzení patří svému operátorovi a svému systému.

Než začnete číst kterýkoli protokol, sledujte dotaz

Dotaz se k resolveru dostane jen tehdy, když se ho cesta skutečně zeptá. Aplikace může použít resolver operačního systému, spustit vlastního šifrovaného DNS klienta nebo přečíst odpověď z mezipaměti a nikdy nic neposlat. Protokol resolveru, který nic neukazuje, tedy není důkazem, že se název nikdy nepoužil; je důkazem, že se tento resolver nezeptali.

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

Poslední příkaz čte vlastní žurnál místního resolveru, což není totéž jako protokol nadřazeného serveru. Pokud vaše dotazy odcházejí přes DNS over HTTPS k poskytovateli, místní stub nemusí ukazovat nic, zatímco poskytovatel má kompletní záznam, a poskytovatel je jiný operátor s jinou zásadou.

Co který záznam může a nemůže ukázat

Spojit je je ta skutečná práce a spojit je není vždy možné. Resolver, který zaznamenává adresy klientů, lze porovnat s VPN, která přiděluje adresy ze známého fondu, a toto porovnání vytváří věrohodné spojení mezi dotazovaným názvem a tunelem, které zůstává spojením mezi dvěma záznamy, nikoli záznamem o člověku.

Šifrované DNS mění přenos, ne viditelnost v koncovém bodě. Resolver stále dostává otázku, na kterou odpovídá, jak RFC 8484 jasně ukazuje, a uchovávání v tomto resolveru je rozhodnutím zásady, nikoli vlastností protokolu.

Kde rozdělené DNS a mezipaměti zamotávají příběh

Více resolverů je normální. Návrh s rozděleným DNS posílá interní názvy na interní server a vše ostatní na veřejný, takže jedno vyšetřování může zahrnovat dva protokoly, které se nikdy neměly kombinovat, a dvě nastavení uchovávání, která se nikdy neměla porovnávat. Vidět dotazy v obou je důkaz, že návrh funguje, ne důkaz úniku.

Mezipaměti řežou opačným směrem. Populární název může být z mezipaměti zodpovídán celé hodiny, takže záznam resolveru ukazuje první dotaz a pak nic, zatímco aplikace uživatele dál v klidu překládá stejný název. Nepřítomnost záznamů po určité době neznamená, že název po této době nikdo nepoužil.

Provoz na pozadí je třetí zkreslení. Telefon, který při startu překládá název telemetrie, prohlížeč, který překládá doménu návrhu vyhledávání, a aktualizátor, který se každou hodinu hlásí, se všechny objevují v protokolu resolveru vedle názvu, na kterém vám skutečně záleží. Objem v tomto protokolu není pozornost a počítání dotazů není počítání návštěv. Protokol resolveru je záznam otázek a otázky se dají generovat levně.

Ptejte se na uchovávání odděleně

U každého systému položte tři otázky: kdo sbírá, co se sbírá a jak dlouho se to uchovává. Pak se zeptejte, kdo to může číst a v jakém procesu. Diskuse k RFC 8484 o DNS over HTTPS je dobrou připomínkou, že šifrovaný přenos neodstraňuje koncový bod, a vlastní dokumentace operátora je jediné spolehlivé tvrzení o tom, co tento koncový bod uchovává.

Když se tvrzení o soukromí týká „VPN“, rozdělte ho před přijetím na části: operátor tunelu, resolver, který tunel poskytuje, jakýkoli nadřazený resolver, k němuž se tyto dotazy dostanou, a aplikace v zařízení. Každá má svou odpověď a tvrzení přesné pro jednu se běžně opakuje, jako by pokrývalo všechny čtyři.

Při řešení potíží použijte stejné rozdělení. Zeptejte se, která aplikace dotaz vytvořila a který resolver na něj odpověděl, a pak se podívejte do protokolu, který té události skutečně patří. Hádání z druhého protokolu ušetří minutu a stojí odpoledne.