Zwykłe zapytanie DNS potrafi zdradzić, z jakimi domenami łączy się użytkownik, nawet gdy odwiedzane strony korzystają z HTTPS. Powód jest prosty: tradycyjny DNS przesyła pytania i odpowiedzi bez szyfrowania, najczęściej przez port 53. Operator sieci, administrator publicznego Wi-Fi lub osoba podsłuchująca ruch może więc odczytać nazwy wyszukiwanych domen. DNS over HTTPS (DoH) i DNS over TLS (DoT) ograniczają ten problem, szyfrując komunikację z serwerem DNS. Oba rozwiązania chronią podobne informacje, ale różnią się sposobem transmisji, konfiguracją i zachowaniem w sieciach firmowych. Wybór nie sprowadza się do tego, który protokół jest bezpieczniejszy. Ważniejsze jest, gdzie ma działać i co powinno się wydarzyć, gdy szyfrowanie zawiedzie.
Jak działają DoH i DoT
DNS tłumaczy nazwy domen, takie jak example.com, na adresy IP potrzebne do nawiązania połączenia. W tradycyjnym modelu urządzenie wysyła zapytanie do resolvera DNS, który ustala odpowiedź, korzystając z pamięci podręcznej lub infrastruktury DNS. Problem polega na tym, że standardowa komunikacja z resolverem przez UDP lub TCP na porcie 53 nie zapewnia poufności.
DoH i DoT szyfrują połączenie między klientem a resolverem, wykorzystując TLS. Różnica tkwi w sposobie transportowania zapytań:
- DNS over HTTPS (RFC 8484) przesyła wiadomości DNS jako żądania HTTPS, zwykle przez port 443. Obsługuje metody HTTP GET i POST oraz może korzystać z HTTP/2 lub HTTP/3.
- DNS over TLS (RFC 7858) przesyła wiadomości DNS bezpośrednio przez połączenie TLS, standardowo na porcie TCP 853. Nie wykorzystuje warstwy HTTP.
- Tradycyjny DNS zwykle korzysta z portu 53 i nie szyfruje treści zapytań ani odpowiedzi.
W praktyce DoH łatwiej wtapia się w zwykły ruch internetowy. Port 443 obsługuje także większość połączeń HTTPS, dlatego samo rozpoznanie po numerze portu jest trudniejsze. DoT działa na osobnym porcie 853, co upraszcza identyfikację i kontrolowanie ruchu przez administratorów.
Przykład? Laptop łączy się z Wi-Fi w hotelu. Przy tradycyjnym DNS zapytanie o domenę banku może zostać odczytane przez urządzenia mające dostęp do ruchu sieciowego. Po włączeniu DoH lub DoT nazwa domeny zostaje zaszyfrowana podczas przesyłania do wybranego resolvera.
DoH będzie praktyczniejszy, gdy urządzenie często korzysta z różnych sieci, w których port 853 bywa blokowany. Nie daje jednak gwarancji przejścia przez każdą zaporę. DoT ma sens, gdy administrator chce jednoznacznie kontrolować szyfrowane zapytania DNS, np. na firmowym routerze.
Oba protokoły mogą korzystać z utrzymywanych połączeń TLS, ograniczając koszt ich ponownego zestawiania. Nie ma natomiast podstaw, aby uznawać jeden z nich za zawsze szybszy. Czas odpowiedzi zależy przede wszystkim od opóźnienia sieciowego, wydajności resolvera, pamięci podręcznej i dostępności serwera.
Istotny jest również tryb awaryjny. Tryb oportunistyczny próbuje używać szyfrowania, ale może przejść na zwykły DNS. Tryb ścisły wymaga bezpiecznego połączenia i w razie problemów przerywa rozwiązywanie nazw. Pierwszy zwiększa dostępność, drugi ogranicza ryzyko niezamierzonego ujawnienia zapytań.
Różnice w konfiguracji przeglądarki, systemu i routera
Największa różnica między DoH i DoT ujawnia się przy konfiguracji. Włączenie szyfrowanego DNS w przeglądarce nie oznacza automatycznie zabezpieczenia całego komputera. Poczta, komunikator czy inne aplikacje mogą nadal korzystać z ustawień systemowych.
W Google Chrome konfigurację DoH znajdziemy w Ustawienia → Prywatność i bezpieczeństwo → Bezpieczeństwo → Użyj bezpiecznego serwera DNS. Można korzystać z obecnego dostawcy lub wskazać innego. Chrome w automatycznym trybie potrafi wrócić do nieszyfrowanego DNS, gdy bezpieczne wyszukiwanie zawiedzie. Przy wybranym niestandardowym dostawcy taki powrót nie jest domyślnym zachowaniem.
Firefox oferuje podobną funkcję w ustawieniach prywatności i bezpieczeństwa. Poziom domyślny dopuszcza mechanizmy awaryjne, natomiast Maksymalna ochrona wymaga DoH i sygnalizuje problemy z resolverem, umożliwiając określone wyjątki. To rozsądny wybór dla użytkownika, który chce świadomie kontrolować ewentualny brak szyfrowania, ale mniej wygodny w sieciach z ograniczeniami.
Na poziomie systemu dostępne są inne możliwości:
- Windows 11: w ustawieniach sieci Wi-Fi lub Ethernet, w sekcji przypisania serwera DNS, można ręcznie wskazać resolver i włączyć DNS przez HTTPS. Dostępny jest szablon automatyczny lub ręczny oraz osobne ustawienie powrotu do nieszyfrowanych zapytań.
- Android 9 i nowsze: funkcja „Prywatny DNS” zwykle korzysta z DoT. W ustawieniach „Sieć i internet → Prywatny DNS” można wybrać nazwę hosta dostawcy, np.
dns.google. Wpisuje się nazwę hosta, a nie sam adres IP8.8.8.8. - Router: obsługa zależy od modelu i oprogramowania. Przykładowo FRITZ!Box udostępnia DNS over TLS, a MikroTik RouterOS obsługuje DNS over HTTPS.
Dla komputera z Windows 11 można wybrać resolver Cloudflare o adresach 1.1.1.1 i 1.0.0.1, a następnie ustawić DoH z automatycznym szablonem, o ile system rozpoznaje wybranego dostawcę. Dla niestandardowych usług potrzebny jest poprawny szablon HTTPS. Samo wpisanie adresu serwera DNS nie włącza szyfrowania.
W mieszkaniu z kilkunastoma urządzeniami wygodniejsze bywa skonfigurowanie routera. FRITZ!Box pozwala wskazać nazwy serwerów DoT, np. dns.google, i określić zachowanie przy awarii. Trzeba jednak uwzględnić istotne ograniczenie: jeśli komputer wysyła zwykły DNS do routera, a dopiero router szyfruje zapytania do zewnętrznego resolvera, odcinek komputer–router pozostaje nieszyfrowany.
Co więcej, przeglądarka korzystająca z własnego DoH może całkowicie ominąć DNS skonfigurowany na routerze. W firmie, która wykorzystuje wewnętrzne nazwy serwerów, prowadzi to do błędów. Publiczny resolver nie zna przecież prywatnych rekordów firmowej infrastruktury.
Dlatego dla pojedynczej przeglądarki najprostszy jest DoH. Dla całego telefonu z Androidem naturalnym wyborem pozostaje systemowy DoT. W rozbudowanej sieci lepiej zacząć od centralnego resolvera i polityki DNS, zamiast niezależnie zmieniać ustawienia każdego programu. Trzeba też sprawdzić obsługę IPv6, ponieważ nieuwzględniona konfiguracja drugiego protokołu IP potrafi zniweczyć część założeń.
Wpływ szyfrowanego DNS na prywatność, filtrowanie i rozwiązywanie problemów
Najczęstsze nieporozumienie dotyczy anonimowości. DoH i DoT nie ukrywają całej aktywności internetowej. Szyfrują zapytania na odcinku klient–resolver, ale sam resolver widzi wyszukiwane domeny oraz adres IP klienta, który się z nim łączy. Dalsze zapytania resolvera do infrastruktury autorytatywnej również nie muszą być szyfrowane.
Dostawca internetu nie odczyta treści prawidłowo zaszyfrowanych zapytań DNS, nadal jednak może obserwować adresy IP połączeń i inne metadane. Nazwa usługi może być ujawniana także przez SNI podczas zestawiania TLS, jeżeli nie zastosowano mechanizmu Encrypted Client Hello (ECH). Samo DoH nie zastępuje VPN, nie usuwa mechanizmów śledzenia w przeglądarce i nie zapewnia anonimowości.
Istnieje również kwestia zaufania. Przełączenie DNS operatora na Google Public DNS czy Cloudflare oznacza przekazanie innemu podmiotowi informacji o zapytaniach. Przy wyborze dostawcy trzeba sprawdzić politykę przechowywania logów, filtrowania domen i przetwarzania danych. Szyfrowanie transportu nie jest równoznaczne z brakiem rejestrowania zapytań.
Drugi problem to filtrowanie. Domowy Pi-hole lub AdGuard Home może blokować domeny reklamowe i szkodliwe. Jeżeli jednak przeglądarka przełączy się na zewnętrzny DoH, zapytania ominą lokalny filtr. W efekcie reklamy wracają, mimo że panel blokowania nadal działa poprawnie.
W przedsiębiorstwie konsekwencje bywają poważniejsze. Niezależny DoH może omijać firmowe reguły DNS oraz split DNS, w którym ta sama domena otrzymuje różne odpowiedzi wewnątrz i poza organizacją. Rozwiązaniem nie jest bezrefleksyjne wyłączenie szyfrowania, lecz wykorzystanie firmowego resolvera obsługującego DoH lub DoT albo odpowiednie wyłączenia dla domen wewnętrznych.
Gdy po zmianie ustawień strony przestają działać, diagnostykę najlepiej prowadzić w określonej kolejności:
- Ustal zakres awarii. Jeśli problem występuje tylko w jednej przeglądarce, sprawdź jej ustawienia DoH przed zmianą konfiguracji całego systemu.
- Sprawdź resolver i tryb awaryjny. Zablokowany port 853, błędny certyfikat lub niedostępny serwer mogą powodować awarię w trybie ścisłym.
- Porównaj działanie nazw publicznych i lokalnych. Jeśli Internet działa, ale wewnętrzne serwery są niedostępne, podejrzewaj ominięcie lokalnego DNS.
- Sprawdź IPv6, VPN i filtry sieciowe. Te elementy mogą korzystać z innych resolverów lub zmieniać trasę zapytań.
W narzędziu Wireshark ruch na TCP 853 jest łatwy do wyodrębnienia, natomiast DoH na porcie 443 trudniej odróżnić od pozostałego HTTPS. Brak pakietów DNS na porcie 53 nie dowodzi jeszcze, że wszystkie aplikacje używają szyfrowania. Podobnie wynik polecenia nslookup nie potwierdza, że przeglądarka korzysta z DoH.
Nie należy też mylić szyfrowanego DNS z DNSSEC. DNSSEC umożliwia weryfikację autentyczności danych DNS, natomiast DoH i DoT chronią transport między klientem a resolverem. Mechanizmy rozwiązują różne problemy i mogą być stosowane równocześnie.
FAQ
Czy DNS over HTTPS jest bezpieczniejszy od DNS over TLS?
Nie z samego powodu używania HTTPS. Oba protokoły zapewniają szyfrowanie TLS. O bezpieczeństwie decydują przede wszystkim poprawna weryfikacja serwera, konfiguracja i polityka awaryjna.
Czy DoH lub DoT spowalniają Internet?
Mogą zwiększyć koszt początkowego zestawienia połączenia, ale utrzymywanie sesji i pamięć podręczna ograniczają ten wpływ. Nie ma gwarancji, że szyfrowany DNS będzie szybszy albo wolniejszy od tradycyjnego.
Czy operator internetu nadal widzi odwiedzane strony?
Nie widzi treści poprawnie zaszyfrowanych zapytań DNS, ale nadal może obserwować adresy IP i część metadanych połączeń. Szyfrowany DNS nie zapewnia pełnej anonimowości.
Co się stanie, jeśli port 853 zostanie zablokowany?
DoT w trybie ścisłym przestanie rozwiązywać nazwy. W trybie oportunistycznym możliwy jest powrót do nieszyfrowanego DNS. DoH przez port 443 może nadal działać, o ile sieć go dopuszcza.
Czy szyfrowany DNS blokuje reklamy i złośliwe strony?
Nie samodzielnie. Filtrowanie zależy od wybranego resolvera i jego reguł. Można używać szyfrowanego DNS bez filtrów albo resolvera, który blokuje wskazane kategorie domen.
Od czego najlepiej zacząć konfigurację?
Od jednego urządzenia i jednego zaufanego resolvera. Najpierw sprawdź, czy rozwiązywanie nazw działa bez powrotu do zwykłego DNS, a następnie zweryfikuj dostęp do lokalnych zasobów i działanie filtrów. Dopiero po takim sprawdzeniu przenieś ustawienia na router lub pozostałe urządzenia.
