Dzienniki resolvera DNS a dzienniki połączeń VPN: co zawiera każdy z nich

Dziennik resolvera DNS i dziennik połączeń VPN są oba zapisami sieciowymi, oba użyteczne i nie są wymienne. Resolver otrzymuje nazwy, o których odpowiedź został poproszony. Punkt końcowy VPN obsługuje połączenia tunelowe i rejestruje to, co jego implementacja zdecydowała się o nich zapisać. Mogą znajdować się w tym samym budynku, być obsługiwane przez ten sam zespół i podlegać tej samej informacji o prywatności, a mimo to opisują różne zdarzenia z różnymi identyfikatorami i różnym przechowywaniem. Czytanie jednego tak, jakby był drugim, to sposób, w jaki śledztwa zbaczają z kursu.

Dwa dzienniki, dwa zdarzenia

Wpis resolvera odpowiada na pytanie o nazewnictwo: ten klient poprosił o tę nazwę w tym momencie, a odpowiedzią było to. Wpis VPN odpowiada na pytanie o łączność: ten peer nawiązał lub utracił tunel, przydzielono mu ten adres i przesłał mniej więcej tyle danych, zanim zniknął. Żaden z nich nie jest zapisem tego, co użytkownik robił wewnątrz sesji HTTPS, i żaden nie zastępuje drugiego.

Rozróżnienie ma praktyczne konsekwencje dla obietnic. Stwierdzenie, że dostawca VPN nie rejestruje aktywności tunelu, nic nie mówi o resolverze, którego udostępnia, a polityka przechowywania resolvera nic nie mówi o tym, kto połączył się z tunelem. Każde twierdzenie należy do swojego operatora i swojego systemu.

Śledź zapytanie, zanim przeczytasz którykolwiek dziennik

Zapytanie dociera do resolvera tylko wtedy, gdy ścieżka rzeczywiście o niego pyta. Aplikacja może używać resolvera systemu operacyjnego, uruchamiać własnego zaszyfrowanego klienta DNS albo odczytać odpowiedź z pamięci podręcznej i nigdy nic nie wysłać. Zatem dziennik resolvera, który nic nie pokazuje, nie jest dowodem, że nazwa nigdy nie była używana; jest dowodem, że ten resolver nie został zapytany.

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

Ostatnie polecenie czyta własny dziennik lokalnego resolvera, co nie jest tym samym co dziennik serwera nadrzędnego. Jeśli Twoje zapytania wychodzą przez DNS over HTTPS do dostawcy, lokalna zaślepka może nic nie pokazywać, podczas gdy dostawca ma pełny zapis, a dostawca jest innym operatorem z inną polityką.

Co każdy zapis może, a czego nie może pokazać

Łączenie ich to prawdziwa praca, a łączenie nie zawsze jest możliwe. Resolver, który rejestruje adresy klientów, można porównać z VPN, który przydziela adresy ze znanej puli, a to porównanie daje prawdopodobne powiązanie między odpytywaną nazwą a tunelem, które pozostaje powiązaniem między dwoma zapisami, a nie zapisem o osobie.

Zaszyfrowany DNS zmienia transport, a nie widoczność w punkcie końcowym. Resolver nadal otrzymuje pytanie, na które odpowiada, jak RFC 8484 jasno pokazuje, a przechowywanie w tym resolverze jest decyzją polityki, a nie właściwością protokołu.

Gdzie podzielony DNS i pamięci podręczne gmatwają historię

Wiele resolverów jest normalne. Projekt z podzielonym DNS wysyła nazwy wewnętrzne do serwera wewnętrznego, a wszystko inne do publicznego, więc jedno śledztwo może obejmować dwa dzienniki, których nigdy nie miało się łączyć, i dwa ustawienia przechowywania, których nigdy nie miało się porównywać. Widok zapytań w obu jest dowodem, że projekt działa, a nie dowodem wycieku.

Pamięci podręczne tną w drugą stronę. Popularna nazwa może być obsługiwana z pamięci podręcznej przez godziny, więc zapis resolvera pokazuje pierwsze zapytanie, a potem nic, podczas gdy aplikacja użytkownika dalej wesoło rozwiązuje tę samą nazwę. Brak wpisów po pewnym czasie nie oznacza, że nikt nie używał nazwy po tym czasie.

Ruch w tle jest trzecim zniekształceniem. Telefon, który przy starcie rozwiązuje nazwę telemetrii, przeglądarka, która rozwiązuje domenę podpowiedzi wyszukiwania, oraz aktualizator, który łączy się co godzinę, pojawiają się w dzienniku resolvera obok nazwy, na której naprawdę Ci zależy. Wolumen w tym dzienniku nie jest uwagą, a liczenie zapytań nie jest liczeniem wizyt. Dziennik resolvera jest zapisem pytań, a pytania są tanie w generowaniu.

Zadawaj pytania o przechowywanie osobno

Dla każdego systemu zadaj trzy pytania: kto zbiera, co jest zbierane i jak długo jest to przechowywane. Potem zapytaj, kto może to czytać i w jakim trybie. Omówienie RFC 8484 dotyczące DNS over HTTPS to dobre przypomnienie, że zaszyfrowany transport nie usuwa punktu końcowego, a dokumentacja samego operatora jest jedynym wiarygodnym stwierdzeniem o tym, co ten punkt końcowy przechowuje.

Gdy pojawia się twierdzenie o prywatności dotyczące „VPN”, podziel je na składniki, zanim je przyjmiesz: operator tunelu, resolver udostępniany przez tunel, każdy nadrzędny resolver, do którego docierają te zapytania, oraz aplikacje na urządzeniu. Każdy ma swoją własną odpowiedź, a twierdzenie trafne dla jednego jest rutynowo powtarzane tak, jakby obejmowało wszystkie cztery.

Do rozwiązywania problemów używaj tego samego podziału. Zapytaj, która aplikacja wykonała zapytanie i który resolver na nie odpowiedział, a następnie zajrzyj do dziennika, który naprawdę jest właścicielem tego zdarzenia. Zgadywanie z drugiego dziennika oszczędza minutę i kosztuje popołudnie.