DoH a DoT: Jaka jest różnica między protokołem DNS over HTTPS a protokołem DNS over TLS?

Za każdym razem, gdy klikasz link lub wpisujesz adres w przeglądarce, Twoje urządzenie wysyła żądanie wyszukiwania do rekurencyjnego serwera DNS. Przez dziesięciolecia tradycyjne serwery DNS przetwarzały te żądania za pośrednictwem protokołów UDP i TCP w trybie jawnym na porcie 53. Ponieważ ruch ten jest całkowicie niezaszyfrowany, każda osoba znajdująca się na trasie komunikacji może prześledzić Twoje nawyki przeglądania stron lub manipulować otrzymanymi przez Ciebie odpowiedziami.

Aby wyeliminować tę utrzymującą się lukę w zabezpieczeniach, organizacja Internet Engineering Task Force (IETF) ustanowiła standardy dla dwóch odrębnych kryptograficznych protokołów transportowych: DNS over TLS (DoT) oraz DNS over HTTPS (DoH). Chociaż oba protokoły szyfrują żądania dotyczące domen między klientem a serwerem rozpoznającym nazwy, działają one na różnych warstwach stosu sieciowego i mają bardzo odmienne skutki dla kontroli sieci przedsiębiorstwa, prywatności użytkowników oraz zarządzania zagrożeniami.

Po co w ogóle szyfrować DNS?

DNS w postaci zwykłego tekstu pozostaje jedną z największych strukturalnych luk w zabezpieczeniach starszej architektury internetowej. Gdy zapytania są przesyłane przez publiczne lub niezaufane połączenia bez szyfrowania, narażają one użytkowników i organizacje na trzy główne zagrożenia:

1. Pasywne podsłuchiwanie: Każdy podmiot mający wgląd w ruch sieciowy — w tym dostawcy usług internetowych (ISP), operatorzy publicznych sieci Wi-Fi oraz programy monitorujące — może rejestrować każde wyszukiwanie domeny przeprowadzane przez Twoje urządzenie. Nawet jeśli późniejszy ruch internetowy odbywa się za pomocą protokołu HTTPS, Twoje zapytania DNS nadal ujawniają dokładnie, z jakimi usługami, aplikacjami i domenami wchodzisz w interakcję.

2. Manipulacja i przechwytywanie w trakcie przesyłania: Osoby atakujące korzystające z tej samej sieci lokalnej mogą przechwytywać żądania w postaci zwykłego tekstu i wstawiać sfałszowane odpowiedzi – jest to taktyka znana jako atak typu „man-in-the-middle”. Pozwala to atakującemu przekierować legalny ruch do złośliwej infrastruktury bez wzbudzania podejrzeń ofiary.

3. Przekierowania i fałszowanie adresów: W typowym scenariuszu fałszowania adresów DNS zmodyfikowane odpowiedzi na zapytania kierują użytkowników na strony phishingowe, które naśladują wewnętrzne portale firmowe, serwisy bankowe lub dostawców usług pojedynczego logowania (Single Sign-On).

Szyfrowanie kanału transmisji między urządzeniem klienckim (modułem stub resolver) a nadrzędnym serwerem rekurencyjnym eliminuje te wektory ataku. Gwarantuje to, że osoby podsłuchujące widzą jedynie zaszyfrowane strumienie danych, a nie nazwy domen w postaci zwykłego tekstu, a jednocześnie zapewnia, że odpowiedzi nie mogą zostać zmodyfikowane przez urządzenia pośredniczące na trasie.

Czym jest DNS over TLS (DoT)?

Protokół DNS over TLS, znormalizowany przez IETF w dokumencie RFC 7858, zabezpiecza klasyczne komunikaty w formacie sieciowym DNS w zaszyfrowanym tunelu Transport Layer Security (TLS).

Zamiast standardowego portu 53, DoT działa na własnym, dedykowanym porcie sieciowym: porcie 853.

Gdy urządzenie inicjuje protokół DoT, nawiązuje niezawodne połączenie TCP z portem 853 wyznaczonego serwera rozpoznającego, przeprowadza standardowy kryptograficzny uzgodnienie TLS oraz wymienia zapytania DNS w ramach tej bezpiecznej sesji. Specyfikacja RFC 7858 zabrania przesyłania danych w postaci zwykłego tekstu przez port 853; jeśli negocjacja TLS zakończy się niepowodzeniem, połączenie zostaje przerwane, a nie przechodzi w tryb transmisji niezaszyfrowanej na tym porcie.

Ponieważ DoT nie dodaje żadnych nakładek na poziomie warstwy aplikacji, minimalizuje to obciążenie związane z wysyłaniem zapytań. Po nawiązaniu połączenia klienci mogą ponownie wykorzystywać istniejące sesje TLS i wysyłać wiele zapytań jednocześnie, co pozwala uniknąć opóźnień związanych z nawiązywaniem połączenia przy każdym wyszukiwaniu.

Obsługa systemów operacyjnych i platform

• Android: Począwszy od wersji Android 9 (Pie) firma Google dodała natywną obsługę protokołu DoT poprzez ustawienie „Prywatny DNS”. Po włączeniu tej funkcji wraz z wybraną nazwą hosta wszystkie zapytania DNS z całego urządzenia są kierowane przez protokół DoT.
• Linux: Systemowe programy rozpoznające nazwy, takie jak systemd-resolved, oraz lokalne demony buforujące, np. Unbound czy Stubby, zapewniają natywną obsługę protokołu DoT.
• Urządzenia klasy korporacyjnej: Nowoczesne zapory sieciowe nowej generacji (NGFW) oraz dedykowane rekurencyjne serwery nazw często obsługują protokół DoT w sposób natywny w celu szyfrowania wewnętrznych zapytań kierowanych do zabezpieczających serwerów nazw wyższego szczebla.

Czym jest DNS przez HTTPS (DoH)?

Protokół DNS over HTTPS, ujednolicony w dokumencie RFC 8484, opiera się na innej architekturze. Zamiast wprowadzać dedykowany kanał transportowy dla zapytań dotyczących domen, DoH enkapsuluje komunikaty żądań i odpowiedzi DNS w standardowych ładunkach HTTP/2 lub HTTP/3 zaszyfrowanych za pomocą protokołu TLS.

DoH działa na porcie 443, czyli tym samym porcie sieciowym, z którego korzysta standardowy ruch internetowy.

Zgodnie z RFC 8484 zapytania DNS są przesyłane jako żądania HTTP GET lub POST o określonym typie MIME „application/dns-message”. Ponieważ wymiana ta jest w pełni multipleksowana wraz z ruchem internetowym na porcie 443, osoby postronne obserwujące sieć z zewnątrz nie są w stanie łatwo odróżnić wyszukiwania DNS od zwykłego pobierania zabezpieczonej strony internetowej.

Taka konstrukcja zapewnia maksymalną odporność prywatności użytkownika końcowego. Jeśli sieć pośrednicząca lub dostawca usług internetowych (ISP) podejmie próbę kontroli lub filtrowania ruchu DNS, protokół DoH uniemożliwi im to, chyba że przełamią zabezpieczenia i przeanalizują wszystkie wychodzące połączenia HTTPS.

Obsługa systemów operacyjnych i przeglądarek

• Przeglądarki internetowe: Mozilla Firefox, Google Chrome, Microsoft Edge i Brave – wszystkie te przeglądarki są wyposażone w konfigurowalne silniki DoH. Firefox jako pierwszy wprowadził domyślne wdrażanie protokołu DoH w wielu regionach, natomiast przeglądarki oparte na silniku Chromium obsługują automatyczne aktualizacje do protokołu DoH, gdy system operacyjny wykorzystuje kompatybilny moduł rozpoznawania adresów.
• Windows 11: System Windows 11 oferuje wbudowaną obsługę protokołu DoH w całym systemie. Administratorzy sieci i użytkownicy mogą przypisywać adresy IP serwerów DNS oraz określać adresy URL szablonów DoH w trybie ręcznym w oknie właściwości karty sieciowej.
• Apple (macOS i iOS): Platformy Apple obsługują protokoły DoH i DoT natywnie za pośrednictwem zaszyfrowanych profili konfiguracyjnych DNS lub dedykowanych aplikacji rozszerzających możliwości sieciowe.

Ministerstwo Zdrowia a Ministerstwo Transportu: porównanie obu instytucji

Wyjaśnienie kluczowych różnic

Przydzielanie portów i wgląd w sieć

Najbardziej wyraźna różnica w działaniu między DoT a DoH dotyczy przypisanych im numerów portów.

Protokół DoT działa na porcie 853. To dedykowane przypisanie sprawia, że monitorowanie sieci jest przewidywalne. Administrator systemu może rzucić okiem na logi zapory sieciowej, sprawdzić, czy ruch na porcie 853 kierowany jest do autoryzowanego wewnętrznego serwera rozpoznającego nazwy, i zablokować nieautoryzowane połączenia za pomocą jednej reguły. Jeśli niezarządzany punkt końcowy próbuje nawiązać połączenie z nieautoryzowanym serwerem rozpoznającym nazwy na porcie 853, zapora odrzuca pakiet bez zakłócania normalnego ruchu internetowego.

Protokół DoH wykorzystuje port 443. Ponieważ przez port 443 przechodzi praktycznie cały zaszyfrowany ruch internetowy, sieć nie może zablokować portu 443 bez odcięcia dostępu do sieci WWW. W rezultacie administratorzy sieci nie są w stanie stwierdzić, czy pakiet wychodzący stanowi zwykłe wywołanie interfejsu API, ładowanie strony internetowej sklepu internetowego przez użytkownika, czy też zaszyfrowane żądanie DNS skierowane do zewnętrznego serwera DNS.

Kompromis między bezpieczeństwem a prywatnością

Ministerstwo Zdrowia (DoH) i Ministerstwo Transportu (DoT) zwracają uwagę na trwającą debatę dotyczącą równowagi między prywatnością użytkowników końcowych a scentralizowaną ochroną sieci.

Pod względem ochrony prywatności użytkowników protokół DoH sprawdza się znakomicie. W publicznych sieciach Wi-Fi lub w regionach, gdzie dostawcy usług rejestrują historię przeglądania stron przez klientów i czerpią z tego zyski, protokół DoH ukrywa metadane zapytań w zwykłym strumieniu ruchu internetowego, chroniąc użytkowników przed inwazyjnym śledzeniem.

Z punktu widzenia bezpieczeństwa korporacyjnego niezarządzany protokół DoH wiąże się ze znacznym ryzykiem. Wiele nowoczesnych systemów zapobiegania zagrożeniom wykorzystuje filtrowanie DNS do przechwytywania znanych domen typu „command-and-control” (C2), powstrzymywania tuneli służących do wycieku danych oraz blokowania punktów końcowych wykorzystywanych w atakach phishingowych, zanim jeszcze rozpocznie się proces uzgadniania połączenia TCP.

Gdy przeglądarka lub złośliwa aplikacja w sieci firmowej domyślnie przełącza się na zewnętrzny protokół DoH:

• Całkowicie omija lokalne zapory DNS i serwery rozpoznające nazwy w usłudze Active Directory.
• Uniemożliwia to narzędziom do zarządzania informacjami i zdarzeniami bezpieczeństwa (SIEM) dostęp do dzienników zapytań punktów końcowych.
• Zaawansowani cyberprzestępcy mogą wykorzystywać kanały DoH do potajemnej komunikacji z zewnętrzną infrastrukturą dowodzenia, ukrywając złośliwe ładunki w zwykłych sesjach na porcie 443.

Z tego powodu korporacyjne zespoły IT często blokują nieautoryzowane punkty końcowe DoH na granicy sieci IP lub wdrażają zasady grupowe, które nakazują korzystanie z serwerów rozpoznających adresy zatwierdzonych przez firmę.

Wydajność i opóźnienie

W codziennych warunkach oba protokoły zapewniają szybką reakcję po nawiązaniu początkowego połączenia. Jednak mechanizmy leżące u ich podstaw powodują subtelne różnice w wydajności.

DoT wykorzystuje surowe dane DNS przesyłane przez TLS. Dzięki temu ramki pozostają zwarte, co pozwala zmniejszyć liczbę bajtów na transakcję. Protokół ten opiera się na standardowych mechanizmach utrzymywania połączenia TCP oraz wznawianiu sesji TLS, co pozwala zminimalizować obciążenie związane z połączeniem.

Protokół DoH wiąże się z nieco większym obciążeniem związanym z przetwarzaniem, ponieważ musi on hermetyzować zapytania DNS w nagłówkach HTTP oraz zarządzać maszynami stanów HTTP. Jednak dzięki temu, że DoH korzysta z multipleksowania w protokołach HTTP/2 i HTTP/3, może obsłużyć setki równoczesnych żądań w ramach jednego strumienia bez blokowania na początku kolejki, wykorzystując jednocześnie mechanizmy buforowania HTTP. W przypadku standardowego przeglądania stron internetowych rzeczywista różnica w opóźnieniach między protokołami DoT a DoH jest rzadko zauważalna dla użytkowników.

Który z nich wybrać?

Wybór między protokołami DoT a DoH zależy od środowiska, wymagań eksploatacyjnych oraz tego, kto zarządza infrastrukturą sieciową.

Użytkownicy indywidualni korzystający z sieci niezaufanych lub publicznych

Jeśli często podróżujesz, pracujesz w kawiarniach lub korzystasz z usług domowych dostawców usług internetowych, którzy monitorują Twoje zapytania, protokół DoH jest zazwyczaj bardziej niezawodnym rozwiązaniem. Włączenie protokołu DoH w swojej ulubionej przeglądarce gwarantuje, że lokalni operatorzy sieci nie będą mogli rejestrować odwiedzanych przez Ciebie domen ani wstawiać skryptów śledzących.

Sieci przedsiębiorstw i korporacji

Organizacje powinny nadać priorytet protokołowi DoT lub ściśle zarządzanemu protokołowi DoH.

W środowiskach korporacyjnych przejrzystość ma charakter bezwzględny. Zespoły IT muszą zadbać o to, by wszystkie stacje robocze, urządzenia mobilne i sprzęt IoT rozpoznawały nazwy za pośrednictwem zatwierdzonych, zabezpieczonych serwerów rozpoznawania nazw.

Aby zachować kontrolę przy jednoczesnym utrzymaniu szyfrowania, przedsiębiorstwa powinny:

• Skonfiguruj punkty końcowe tak, aby korzystały z wewnętrznych rekurencyjnych serwerów nazw za pośrednictwem protokołu DoT.
• Należy wdrożyć zasady administracyjne w przeglądarkach takich jak Chrome, Edge i Firefox, aby uniemożliwić użytkownikom lub aktualizacjom przełączanie się na niezarządzane publiczne serwery rozdzielające DoH.
• Należy zablokować w zaporach sieciowych ruch wychodzący kierowany do znanych publicznych adresów IP serwerów rozpoznających adresy DoH, aby zapobiec obejściu wewnętrznych mechanizmów zabezpieczeń.
• Należy stosować sprawdzone najlepsze praktyki w zakresie bezpieczeństwa DNS, aby zapewnić jednolitą ochronę we wszystkich strefach wewnętrznych.

Urządzenia mobilne

Urządzenia mobilne nieustannie przełączają się między zaufanymi sieciami Wi-Fi w firmie, routerami domowymi a stacjami bazowymi operatorów komórkowych. System Android radzi sobie z tym płynnie dzięki wbudowanej funkcji Private DNS wykorzystującej protokół DoT, zapewniając jednolite szyfrowanie we wszystkich aplikacjach na urządzeniu bez konieczności instalowania oddzielnego oprogramowania. Urządzenia z systemami iOS i macOS mogą uzyskać taką samą ochronę dzięki profilom konfiguracyjnym obsługującym protokoły DoT lub DoH.

A co z protokołem DNS over QUIC (DoQ)?

Wraz z rozwojem architektur transportowych w dyskusji pojawił się nowy protokół: DNS over QUIC (DoQ), ujednolicony w dokumencie RFC 9250.

Podczas gdy protokoły DoT i starsza wersja DoH działają w oparciu o protokół TCP, protokół DoQ działa w oparciu o protokół QUIC na porcie UDP 853. Protokół QUIC integruje szyfrowanie TLS 1.3 bezpośrednio z procedurą nawiązywania połączenia. Taka struktura rozwiązuje problem blokowania na początku kolejki (head-of-line blocking), przyspiesza nawiązywanie połączenia dzięki wznowieniu sesji z zerowym opóźnieniem (0-RTT) oraz umożliwia płynną migrację połączenia, gdy urządzenia mobilne przełączają się między sieciami Wi-Fi a sieciami komórkowymi.

Chociaż DoQ stanowi najnowocześniejsze rozwiązanie w dziedzinie badań nad szyfrowanym DNS i jego wydajnością, jego wdrażanie w środowisku produkcyjnym pozostaje wciąż w początkowej fazie w porównaniu z dojrzałymi ekosystemami DoT i DoH.

DoH/DoT a DNSSEC: dlaczego potrzebujesz obu rozwiązań

Powszechnym błędnym przekonaniem jest to, że włączenie protokołów DoH lub DoT sprawia, że inne protokoły bezpieczeństwa DNS stają się zbędne. W rzeczywistości szyfrowany transport oraz rozszerzenia bezpieczeństwa systemu nazw domenowych (DNSSEC) dotyczą dwóch zupełnie różnych etapów cyklu życia zabezpieczeń.

• Protokoły DoH i DoT zabezpieczają ścieżkę transmisji: szyfrują połączenie między Twoim urządzeniem a rekurencyjnym serwerem nazw. Zapobiegają one podsłuchiwaniu zapytania przez osoby w Twojej sieci lokalnej lub przez dostawcę usług internetowych. Nie dają one jednak żadnej pewności co do tego, czy serwer nazw wyższego szczebla dostarcza prawidłową odpowiedź od prawdziwego właściciela domeny.
• DNSSEC chroni integralność danych: DNSSEC wykorzystuje kryptograficzne podpisy cyfrowe (rekordy RRSIG) opublikowane w pliku strefy w celu sprawdzenia, czy zwrócone dane DNS nie zostały zmienione na poziomie serwera autorytatywnego ani zafałszowane w pamięciach podręcznych programów rozpoznających.

Jeśli osoba atakująca przejmie kontrolę nad nadrzędnym serwerem nazw lub przeprowadzi atak typu „DNS cache poisoning”, protokoły DoH i DoT przekażą tę sfałszowaną odpowiedź bezpośrednio do urządzenia użytkownika za pośrednictwem bezpiecznego, szyfrowanego tunelu.

Aby zapewnić pełną integralność infrastruktury, organizacje muszą wdrożyć protokół DNSSEC we wszystkich swoich strefach domenowych, konfigurując jednocześnie serwery rozpoznające tak, aby weryfikowały podpisy. Można sprawdzić, czy aktualne domeny publikują prawidłowe podpisy kryptograficzne, poddając je analizie za pomocą naszego automatycznego narzędzia do sprawdzania zgodności z protokołem DNSSEC.

Najczęściej zadawane pytania

Czy protokół DoH jest bezpieczniejszy niż protokół DoT?

Z czysto kryptograficznego punktu widzenia żaden z tych protokołów nie jest z natury bezpieczniejszy od drugiego. Oba wykorzystują solidne szyfrowanie TLS, aby chronić zapytania DNS przed obserwacją i manipulacją. Prawdziwa różnica polega na widoczności w sieci: protokół DoH zapewnia większą prywatność przed monitorowaniem w sieci lokalnej dzięki współdzieleniu portu 443 z ruchem internetowym, natomiast protokół DoT oferuje zespołom ds. bezpieczeństwa w przedsiębiorstwach lepsze możliwości zarządzania dzięki wykorzystaniu dedykowanego portu 853.

Czy powinienem włączyć czy wyłączyć DNS przez HTTPS?

W przypadku użytkowników indywidualnych korzystających z urządzeń osobistych pozostawienie funkcji DoH włączonej zapewnia natychmiastowe korzyści w zakresie prywatności, uniemożliwiając operatorom sieci lokalnych i dostawcom usług internetowych rejestrowanie zapytań.

Jednak w środowiskach korporacyjnych niekontrolowany protokół DoH powinien zazwyczaj być wyłączony lub przekierowany do serwerów rozpoznających adresy zatwierdzonych przez firmę. Gdy nie jest on kontrolowany, protokół DoH na poziomie przeglądarki omija wewnętrzne zapory sieciowe, reguły filtrowania treści oraz urządzenia monitorujące zagrożenia.

Czy można zablokować DoH w sieci?

Tak. Chociaż nie da się zablokować protokołu DoH poprzez zamknięcie konkretnego portu bez jednoczesnego wyłączenia ruchu HTTPS na porcie 443, organizacje mogą ograniczyć korzystanie z DoH za pomocą alternatywnych środków kontroli. Administratorzy sieci mogą zablokować dostęp do publicznych adresów IP znanych komercyjnych serwerów rozpoznających adresy DoH, ograniczyć dostęp za pośrednictwem serwerów proxy lub stosować zapory sieciowe nowej generacji wyposażone w silniki identyfikacji aplikacji (App-ID), które potrafią rozpoznawać sygnatury ruchu DoH.

Czy VPN eliminuje potrzebę stosowania protokołów DoH lub DoT?

Wirtualna sieć prywatna (VPN) szyfruje cały ruch sieciowy opuszczający urządzenie, w tym zapytania DNS, w ramach zaszyfrowanego tunelu prowadzącego z powrotem do bramy VPN. Jeśli ufasz dostawcy VPN i skonfigurujesz system tak, aby zapytania były rozpatrywane przez jego prywatne rekurencyjne serwery nazw, niekoniecznie potrzebujesz protokołów DoH lub DoT, ponieważ cały tunel jest już zaszyfrowany.

Jednak korzystanie z protokołów DoH lub DoT zarówno w sieci VPN, jak i poza nią zapewnia wielopoziomową ochronę, gwarantując, że zapytania pozostają zabezpieczone, nawet jeśli w wyniku tunelowania częściowego dochodzi do wycieku standardowych pakietów DNS.

Podsumowanie: Chroń swoje serwery rozpoznające nazwy i swoje wpisy

Zarówno protokół DNS over HTTPS, jak i DNS over TLS zapewniają znaczną poprawę prywatności w porównaniu z czterdziestoletnim standardem przesyłania danych w postaci zwykłego tekstu przez port UDP 53. Wybór między nimi zależy od kontekstu: protokół DoH zapewnia indywidualnym użytkownikom anonimowość i prywatność w sieciach publicznych, natomiast protokół DoT zapewnia organizacjom jasno określone granice i przejrzystość niezbędne do egzekwowania korporacyjnych zasad bezpieczeństwa.

Jednak szyfrowanie sposobu, w jaki Twój zespół wyszukuje domeny stron trzecich, rozwiązuje jedynie połowę problemu związanego z narażeniem Twojej infrastruktury. Musisz również zabezpieczyć publiczne rekordy DNS, które kierują resztę świata do usług internetowych, aplikacji i serwerów pocztowych Twojej firmy.

Niemonitorowane strefy domen są narażone na nieautoryzowane zmiany wpisów, brak podpisów kryptograficznych oraz wygasłe certyfikaty. PowerDMARC pomaga organizacjom zachować pełną kontrolę nad domenami dzięki monitorowaniu bezpieczeństwa DNS i zapewnianiu zgodności z przepisami.

Łącząc ciągłe monitorowanie rekordów i powiadomienia o zmianach w osi czasu DNS z naszym bezpłatnym narzędziem do sprawdzania DNSSEC, możesz zapewnić, że infrastruktura DNS Twojej firmy pozostanie podlegająca audytowi, zgodna z przepisami i zabezpieczona przed spoofingiem pod każdym względem.