DNSSEC czy VPN: co naprawdę ukrywa twoje zapytania DNS?

Dwa mechanizmy dostają to samo zadanie i żaden go nie wykonuje. DNSSEC odpowiada, czy otrzymane dane naprawdę pochodzą ze strefy, która je publikuje, a VPN decyduje, którą drogą pójdą twoje pakiety. Żaden z nich nie ukrywa we wszystkich przypadkach nazwy, o którą pytałeś, a ustawienia, które wyglądają, jakby miały to robić, dotyczą zwykle transportu albo trasowania, a nie walidacji. Nazwanie warstwy na początku zamienia mgliste pytanie o prywatność w konkretne.

Trzy twierdzenia stopione w jedno

Autentyczność to twierdzenie, że odpowiedź jest tą, którą opublikowała strefa, i nie została zmieniona po drodze. Poufność to twierdzenie, że nikt na drodze nie może odczytać zapytania ani odpowiedzi. Trasowanie to twierdzenie, że pakiety idą drogą, którą wybrałeś, i właśnie to daje tunel.

DNSSEC zajmuje się pierwszym i nic nie mówi o pozostałych dwóch. DoT i DoH zajmują się drugim dla odcinka do resolvera. VPN zajmuje się trzecim i może też wpływać na drugie, ale tylko jako efekt uboczny tego, dokąd idzie ruch.

Ruch aplikacji to czwarty przypadek: HTTPS chroni i uwierzytelnia wymianę webową między twoim klientem a witryną, i żadna warstwa DNS go nie zastępuje.

Co walidacja podpisów może, a czego nie może

Resolver walidujący sprawdza łańcuch podpisów od strefy do skonfigurowanej kotwicy zaufania, a następnie zwraca odpowiedź z ustawioną flagą uwierzytelnionych danych, gdy sprawdzenie się powiedzie. Ta flaga jest dowodem dotyczącym danych, a nie połączenia czy intencji celu.

Nie może powstrzymać legalnego właściciela strefy przed publikowaniem autentycznych rekordów dla usługi, której nie powinieneś ufać. Poprawnie podpisana odpowiedź z przejętej domeny nadal jest poprawnie podpisana, a DNSSEC nie ma zdania na temat tego, czy ta domena zasługuje na twoje dane logowania.

Nie ukrywa też niczego. Zapytanie i odpowiedź przechodzą przez sieć w formie, którą resolver i każdy obserwator na tej drodze mogą odczytać, chyba że inna warstwa chroni transport. Odpowiedź podpisana i odpowiedź prywatna to różne właściwości, a wdrożenie może mieć tylko jedną z nich. Przetestuj obie, jeśli którakolwiek ma dla ciebie znaczenie.

Skąd naprawdę bierze się poufność

Szyfrowany transport do resolvera opakowuje wymianę DNS w TLS, więc resolver nadal widzi pytanie, ale droga między tobą a nim nie. To przenosi zaufanie, zamiast je usuwać: bardziej ufasz resolverowi, a mniej sieci lokalnej.

VPN może przenosić zapytania do resolvera po drugiej stronie, co zmienia zarówno drogę, jak i resolver, który je widzi. To decyzja o trasowaniu z konsekwencją dla prywatności, a w zarządzanej sieci wewnętrzny resolver może być jedynym, który potrafi odpowiedzieć na nazwy wewnętrzne.

Kombinacja, której ludzie naprawdę chcą, to zwykle trzy rzeczy naraz: włączona walidacja, szyfrowany transport do wybranego przez nich resolvera i TLS aplikacji w miejscu docelowym. Każda jest niezależna, a pominięcie jednej zostawia inną lukę.

Sprawdzaj walidację i transport osobno

Dwa testy rozwiązują większość zamieszania. Pierwszy pyta, czy resolver zwalidował odpowiedź; drugi, czy transport był chroniony. Zawodzą na różne sposoby i żaden nie implikuje drugiego.

Te polecenia wypisują flagi z zapytania walidującego, powtarzają zapytanie z wyłączonym sprawdzaniem i uruchamiają lokalną walidację za pomocą delv:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

Odpowiedź z flagą uwierzytelnionych danych i obecnym podpisem pokazuje walidację na tym resolverze. Błąd walidacji z delv pokazuje zerwany łańcuch gdzieś między strefą a kotwicą zaufania, co jest problemem publikacji, a nie problemem tunelu. Przekroczenie czasu bez żadnych flag to problem transportu lub osiągalności, a traktowanie go jako błędu podpisu kieruje cię na niewłaściwą warstwę.

Co robić, gdy VPN psuje wyszukiwanie

Jeśli wyszukiwanie działało przed tunelem i zatrzymuje się po nim, porównaj resolver, którego używa każda droga. Podzielony tunel, wewnętrzny resolver osiągalny tylko przez tunel i klient, który nadpisuje ustawienia resolvera, wszystkie zmieniają odpowiedź bez dotykania DNSSEC.

Globalne wyłączenie walidacji to zły pierwszy krok, ponieważ usuwa jedyny mechanizm zgłaszający manipulacje i nie naprawia nieosiągalnego resolvera. Najpierw zawęź usterkę: rozwiązywanie, transport, walidacja, potem polityka. Tylko trzecie należy do DNSSEC, a tylko drugie do szyfrowanego transportu.