Bezpieczeństwo DNS: DoH i DoT

System nazw domen tłumaczy czytelne dla człowieka nazwy domen na adresy IP. Standardowe zapytania DNS korzystają z UDP na porcie 53 i są przesyłane całkowicie bez szyfrowania. Każda nazwa domeny wyszukiwana przez urządzenie jest widoczna dla routera, dostawcy usług internetowych oraz każdego, kto może monitorować ścieżkę sieciową. Oznacza to, że aktywność związana z przeglądaniem Internetu jest ujawniona, nawet gdy każda odwiedzana strona korzysta z HTTPS.

Dostawcy usług internetowych rutynowo rejestrują zapytania DNS wszystkich klientów w ramach monitorowania sieci oraz w celu spełnienia wymogów przepisów dotyczących przechowywania danych obowiązujących w wielu jurysdykcjach. Taki rejestr stanowi szczegółową historię każdej odwiedzonej strony, czasu każdej wizyty i częstotliwości dostępu. Dostawcy usług internetowych sprzedawali te dane reklamodawcom oraz odpowiadali na żądania władz dotyczące historii przeglądania abonentów, opierając się wyłącznie na rejestrach DNS.

Atakujący, który może przechwytywać lub przekierowywać ruch DNS, może modyfikować odpowiedzi tak, aby kierowały użytkowników do złośliwych serwerów. Do przejęcia DNS może dojść na poziomie routera (jeśli router został zaatakowany), za pośrednictwem nieautoryzowanych serwerów DHCP dostarczających adresy resolverów DNS kontrolowanych przez atakującego lub w wyniku przekierowania na poziomie dostawcy usług internetowych. Użytkownicy wpisujący prawidłową nazwę domeny mogą zostać po cichu przekierowani do strony phishingowej, bez żadnego sygnału o przekierowaniu.

Gdy urządzenie dołącza do sieci, żąda konfiguracji za pośrednictwem DHCP, który dostarcza adres IP, bramę i serwer DNS. Atakujący w lokalnej sieci, uruchamiając nieautoryzowany serwer DHCP, może odpowiedzieć szybciej niż prawidłowy serwer i podać własny adres serwera DNS. Wszystkie kolejne zapytania DNS ofiary trafiają do resolvera atakującego, co umożliwia monitorowanie zapytań i modyfikowanie odpowiedzi przez całą sesję.

W 2008 roku badacz Dan Kaminsky ujawnił krytyczną lukę w DNS. Wysyłając tysiące sfałszowanych odpowiedzi DNS z losowymi identyfikatorami transakcji, atakujący mógł statystycznie zatruć pamięć podręczną resolvera, zanim ten otrzymał prawidłową odpowiedź. Atak ten jest znany jako zatrucie pamięci podręcznej w stylu ataku urodzinowego. Zatruta pamięć podręczna przekierowuje wszystkich użytkowników danego resolvera do adresów IP kontrolowanych przez atakującego dla zatrutej domeny.

DNSSEC (DNS Security Extensions) przeciwdziała zatruciu pamięci podręcznej i fałszowaniu odpowiedzi, dodając podpisy kryptograficzne do rekordów DNS. Każda strefa DNS podpisuje swoje rekordy kluczem prywatnym, a resolvery weryfikują podpisy za pomocą odpowiadającego mu klucza publicznego opublikowanego w rekordach DNSKEY. Sfałszowana lub zmodyfikowana odpowiedź nie przejdzie weryfikacji podpisu i zostanie odrzucona. DNSSEC tworzy łańcuch zaufania od głównej strefy DNS aż do rekordów poszczególnych domen.

DNS-over-TLS (DoT) umieszcza zapytania DNS w standardowym połączeniu TLS na porcie 853. Resolver i klient wykonują uzgadnianie TLS przed wysłaniem jakichkolwiek zapytań DNS, szyfrując zarówno zapytanie (w tym nazwę domeny), jak i odpowiedź. DoT zapobiega pasywnemu nadzorowi prowadzonemu przez dostawców usług internetowych i obserwatorów sieci. Korzystanie z dedykowanego portu (853) ułatwia zaporom sieciowym rozpoznanie tego ruchu, dlatego niektóre sieci używają go do blokowania DoT.

DNS-over-HTTPS (DoH) koduje zapytania DNS jako żądania HTTPS na porcie 443, czyli tym samym porcie, który jest używany przez cały ruch internetowy. Ponieważ ruch DoH jest nieodróżnialny od zwykłego HTTPS, zapory sieciowe nie mogą go łatwo blokować bez jednoczesnego blokowania całego ruchu HTTPS. DoH jest natywnie obsługiwane w przeglądarkach Firefox i Chrome oraz w systemie Windows 11, a dostawcy tacy jak Cloudflare (1.1.1.1) i Google (8.8.8.8) udostępniają punkty końcowe DoH.

W przypadku DoH lub DoT zapytania DNS są szyfrowane podczas przesyłania między urządzeniem a resolverem DNS. Dostawca usług internetowych nie może odczytywać ani rejestrować poszczególnych nazw domen, o które pytasz. Ataki z użyciem nieautoryzowanego DHCP nie mogą wstrzyknąć resolvera odczytującego Twój ruch, ponieważ prawidłowy resolver jest zapisany na stałe. Atakujący w sieci nie mogą przeprowadzić przejęcia DNS przez pasywne przechwycenie ruchu. Jednak sam resolver DNS nadal widzi wszystkie Twoje zapytania.

Dostawcy usług internetowych lobbowali przeciwko obowiązkowemu wdrażaniu DoH, ponieważ przenosi ono widoczność DNS od dostawców usług internetowych do niewielkiej liczby resolverów należących do dużych firm technologicznych. Dostawcy usług internetowych w Wielkiej Brytanii skarżyli się parlamentowi, że DoH uniemożliwi filtrowanie treści w ramach kontroli rodzicielskiej. Administratorzy sieci twierdzą, że scentralizowane DoH łamie zasady DNS obowiązujące w przedsiębiorstwach oraz konfiguracje split-horizon DNS. IETF ustandaryzowała DoH w dokumencie RFC 8484, ale zasady wdrażania nadal są przedmiotem sporu.

DNSSEC wymaga zarówno podpisania strefy przez właściciela domeny, jak i przeprowadzania walidacji przez resolver. Rotacja kluczy (zmiana kluczy podpisujących bez przerwy w działaniu usługi) jest złożona i powodowała awarie głównych TLD. Błędnie skonfigurowany DNSSEC może całkowicie uniemożliwić dostęp do domeny. Domeny najwyższego poziomu .com i .net obsługują DNSSEC, ale podpisana jest tylko mniejszość poszczególnych domen. DNSSEC nie szyfruje zapytań; prywatność zapytań zapewniają wyłącznie DoH i DoT.

Standardowy DNS korzystający z UDP na porcie 53 jest nieszyfrowany, a jego zapytania są rejestrowane przez dostawców usług internetowych. Przejęcie DNS i ataki zatruwania pamięci podręcznej Kaminsky’ego wykorzystują tę słabość. DNSSEC dodaje podpisy kryptograficzne, aby zapobiegać fałszowaniu odpowiedzi, ale nie szyfruje zapytań. DoT na porcie 853 i DoH na porcie 443 szyfrują zapytania DNS podczas przesyłania. DoH trudniej zablokować niż DoT. Szyfrowany DNS przenosi zaufanie od dostawców usług internetowych do operatorów resolverów, ale nie eliminuje potrzeby zaufania.