DNS over HTTPS a DNS over TLS

DNS over HTTPS (DoH) i DNS over TLS (DoT) szyfrują wymianę DNS między klientem a wybranym przez niego resolverem. Oba chronią ten odcinek ścieżki przed przypadkowym podglądem i modyfikacją w sieci. Żaden z nich nie sprawi jednak, że przeglądanie stron stanie się całkowicie niewidoczne czy anonimowe.

Jak przesyłane są zapytania

DoH przenosi zapytania i odpowiedzi DNS w wymianach HTTPS; protokół definiuje RFC 8484. DoT przesyła komunikaty DNS w dedykowanym połączeniu TLS, opisanym w RFC 7858. Oba wymagają obsługi po stronie klienta i resolvera oraz uwierzytelnienia resolvera. Samo ustawienie „bezpieczny DNS” nie mówi, który dostawca jest wybrany ani czy urządzenie może wrócić do zwykłego DNS.

DoH jest często wbudowany w przeglądarkę lub aplikację i może korzystać ze zwykłej infrastruktury HTTPS. DoT jest zwykle konfigurowany przez system operacyjny lub sieć i używa odrębnego połączenia DNS. To typowe wzorce, a nie gwarancje: rzeczywiste działanie zależy od urządzenia, aplikacji i polityki sieci. Ani numer portu, ani nazwa protokołu nie dowodzą, że usługa jest godna zaufania.

Co pozostaje widoczne

Operator wybranego resolvera otrzymuje zapytania potrzebne do udzielenia odpowiedzi. Docelowa strona widzi połączenie, a inni uczestnicy sieci mogą widzieć adresy IP połączenia i inne metadane. Szyfrowany DNS nie usuwa historii przeglądarki, plików cookie, zalogowań do kont ani informacji przesyłanych do strony. Przy decyzjach dotyczących prywatności przeanalizuj całą ścieżkę połączenia i politykę danych resolvera.

DNSSEC służy innemu celowi. Może weryfikować pochodzenie i integralność podpisanych danych DNS, gdy skonfigurowany jest łańcuch zaufania; nie szyfruje zapytań między klientem a resolverem. Resolver DoH lub DoT może również walidować DNSSEC. Te mechanizmy się uzupełniają, a nie zastępują. Odpowiedzi serwerów DNS sprawdzisz też w narzędziu 2IP „Sprawdź czas odpowiedzi DNS”.

Sprawdź rzeczywistą konfigurację

Ustal, czy przeglądarka korzysta z systemowej konfiguracji DNS, czy z własnego szyfrowanego resolvera. Porównaj oczekiwaną odpowiedź z wynikiem narzędzia „Sprawdź konfigurację domeny” i zapytaniem przez wybrany resolver. Różnice nie zawsze oznaczają wyciek: CDN może dopasowywać odpowiedzi do lokalizacji resolvera i innych warunków. Sprawdź też, co się dzieje, gdy szyfrowany resolver jest niedostępny.

W sieci zarządzanej filtrowanie, nazwy wewnętrzne i polityka bezpieczeństwa mogą wymagać konkretnego resolvera. Dowolna zmiana DNS może zepsuć dostęp do zasobów wewnętrznych. Zanim zmienisz ustawienia, ustal, kto zarządza siecią, które nazwy muszą być rozwiązywane i czy dozwolona jest alternatywna ścieżka DNS.

Wybieraj świadomie

Oceniaj dostępność dostawcy, sposób przetwarzania danych, walidację DNSSEC i zachowanie w razie awarii, a nie pojedynczą obietnicę prywatności. Po zmianie przetestuj zwykłe strony i potrzebne nazwy wewnętrzne. Jeśli źródłem problemu jest błędny rekord autorytatywny, zmiana transportu DNS go nie naprawi.