Zaszyfrowany DNS bez VPN ukrywa zapytanie, nie twój adres

Test wycieku DNS, który pokazuje twoją sieć domową, nie jest dowodem, że zaszyfrowany DNS zawiódł, ani dowodem, że cokolwiek zadziałało. Test odpowiada na jedno pytanie: do którego resolvera dotarło to zapytanie z tej sieci. To, czy jest to problem, zależy od tego, czego i przed kim chroniłeś.

Zapisz cel, zanim uruchomisz jakikolwiek test.

Krok 1: nazwij ochronę, której naprawdę chcesz

Trzy cele się mieszają. Możesz chcieć, aby obserwator na ścieżce przestał czytać zapytania. Możesz chcieć, aby konkretny resolver przestał je otrzymywać. Możesz chcieć, aby strony, które odwiedzasz, przestały widzieć twój adres domowy. Zaszyfrowany DNS służy pierwszemu, zmienia, kto spełnia drugi, a dla trzeciego nie robi absolutnie nic.

VPN służy trzeciemu i, w zależności od dostawcy, pierwszemu. Żadne z tych narzędzi nie jest nadzbiorem drugiego.

Krok 2: wybierz resolver i zweryfikuj jego tożsamość

DNS over TLS opakowuje zapytanie w sesję TLS z resolverem, a DNS over HTTPS opakowuje je w żądanie HTTP; RFC 7858 i RFC 8484 opisują oba i żadne nie wymaga tunelu. Operacyjnie ważne jest, aby certyfikat był weryfikowany wobec nazwy, którą skonfigurowałeś, ponieważ zaszyfrowana sesja z niewłaściwą stroną jest gorsza niż czysty tekst z właściwą. To oznacza tryb ścisły tam, gdzie platforma go oferuje, a nie tryb oportunistyczny, który wycofuje się, gdy weryfikacja zawiedzie. Sprawdź sesję bezpośrednio, zanim zaufasz ustawieniu: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Uścisk dłoni powinien nazwać skonfigurowany resolver i zwrócić łańcuch, który możesz zweryfikować.

Krok 3: zdecyduj o zachowaniu przy awarii

Każda implementacja ma politykę dla nieosiągalnego zaszyfrowanego resolvera i ta polityka jest decyzją o prywatności. Tryb ścisły powoduje niepowodzenie wyszukiwania, co jest widoczne i irytujące. Tryb oportunistyczny ponawia w czystym tekście, co jest niewidoczne i niweczy cel dokładnie w dniu, w którym ma to znaczenie. Wybierz świadomie, a następnie zapisz wybór obok wymagania.

W systemd-resolved oznacza to DNSOverTLS=yes zamiast opportunistic; a w Androidzie oznacza tryb nazwy hosta Private DNS zamiast automatycznego.

Sprawdź, co jest rzeczywiście w mocy, za pomocą resolvectl status | grep -i -A1 "dns over tls", ponieważ plik drop-in, który nigdy nie został ponownie wczytany, niczego nie zmienia.

Krok 4: sprawdź, czy aplikacje podążają za resolverem systemowym

Przeglądarka z własnym ustawieniem bezpiecznego DNS całkowicie omija konfigurację systemu, podobnie jak środowisko uruchomieniowe kontenerów z wbudowanym resolverem lub środowisko języka, które czyta twardo zakodowaną listę. Albo skłoń je do podążania za systemem, albo skonfiguruj je jawnie i zapisz to. Potem przyjrzyj się zachowaniu awaryjnemu każdego z nich, ponieważ nie wszystkie zawiodą w sposób zamknięty. Inwentarz w praktyce jest krótki: przeglądarka, środowisko kontenerów i dowolny klient VPN, który również uruchamiasz.

Prywatne nazwy organizacji pozostają na zatwierdzonym wewnętrznym resolverze. Wysyłanie ich do usługi publicznej, aby test wyglądał schludnie, celowo tworzy inny problem.

Krok 5: czytaj test wycieku wobec wymagania

Test, który zgłasza nieoczekiwany resolver, jest wskazówką, nie wyrokiem. Być może zaobserwował zamierzony zaszyfrowany resolver, ustawienie specyficzne dla aplikacji albo powrót do czystego tekstu, o którym nie wiedziałeś. Porównaj zgłoszony resolver z tym, co skonfigurował krok 2, i porównaj wynik z celem z kroku 1.

Jeśli celem było trzymanie zapytań z dala od sieci lokalnej, test pokazujący twój zwykły resolver jest prawdziwym ustaleniem. Jeśli celem była anonimowość podczas przeglądania, żadne ustawienie DNS by tego nie dało.

Zapisz warunek akceptacji w języku celu: te wyszukiwania korzystają z tego zweryfikowanego resolvera w tych warunkach. Wszystko szersze jest twierdzeniem, którego nie możesz przetestować.