- DoH dodaje szyfrowanie do zapytań DNS za pomocą protokołu HTTPS, zwiększając prywatność i bezpieczeństwo, zabezpieczając je przed podsłuchiwaniem i manipulacją.
- Nie jest to odpowiednik sieci VPN: chroni wyszukiwania domen, ale nie cały ruch ani adres IP.
- Jego wdrożenie ma zalety wydajnościowe, ale także stwarza napięcia związane z kontrolą rodzicielską, monitorowaniem i cenzurą.
Podczas wpisywania adresu internetowego w tle działa komponent, który zapewnia dotarcie do właściwej witryny: system nazw domen (DNS). DNS tłumaczy łatwe do zapamiętania nazwy na adresy IP zrozumiałe dla komputerów. To wygodne, owszem, ale przez lata funkcjonowało z istotną luką w zabezpieczeniach: zapytania te były przesyłane bez szyfrowania. Właśnie dlatego protokół DNS przez HTTPS, znany również jako DoH, stał się tak popularny – to dodatkowa warstwa ochrony, która utrudnia dostawcy usług internetowych śledzenie odwiedzanych domen.
Na wstępie warto wyjaśnić jedną rzecz: DoH poprawia prywatność zapytań DNS, ale nie jest VPN-em ani nie zmienia całego połączenia w tajny tunel . W tym artykule dokładnie wyjaśnimy, czym jest, dlaczego zyskał popularność, jak go aktywować w przeglądarkach Chrome, Edge i Firefox, jego zalety i wady, czym różni się od DNS przez TLS i VPN-a, a także jakie są jego ograniczenia techniczne i praktyczne.
Czym jest DNS i dlaczego tradycyjny system jest niewystarczający?
Serwery DNS to jeden z tych komponentów, na które prawie nikt nie zwraca uwagi, a mimo to stanowią one podstawę przeglądania stron internetowych. Ich zadaniem jest powiązanie nazwy domeny z adresem IP odpowiedniego serwera . Podczas odwiedzania strony internetowej komputer nie rozumie liter: potrzebuje adresu IP, aby wiedzieć, z którym komputerem się połączyć. Wiele routerów jest wyposażonych w serwery DNS skonfigurowane przez dostawcę usług internetowych, co ułatwia cały proces, a jednocześnie pozostawia widoczny ślad dla osoby kontrolującej infrastrukturę.
Podstawowym problemem jest to, że tradycyjne zapytania DNS są wysyłane w postaci zwykłego tekstu i bez zabezpieczeń . Otwiera to drogę do podsłuchu, ataków typu man-in-the-middle i manipulacji odpowiedzią. Dostawca usług internetowych może dowiedzieć się, które domeny i kiedy są odpytywane; atakujący w sieci współdzielonej może próbować przechwycić żądanie i zwrócić fałszywą odpowiedź. Ta technika jest znana jako przechwytywanie DNS i może ostatecznie doprowadzić do fałszywej strony, niechcianej reklamy lub witryny mającej na celu kradzież danych. Rządy i dostawcy usług internetowych również historycznie wykorzystywali te słabości do wprowadzania cenzury, blokowania domen lub wyświetlania dodatkowych reklam.
- Słuchanie pasywne: Ktoś obserwuje zapytania i wnioskuje, z jakich usług lub stron internetowych korzystasz.
- Człowiek-pośrednik: Komunikacja zostaje przechwycona, a odpowiedź zmodyfikowana tak, aby podszywać się pod serwer.
- Blokowanie i filtrowanie: Zapobiega rozstrzyganiu niektórych domen w celu kontrolowania dostępu do treści.
DNS przez HTTPS: Zaszyfruj zapytanie, aby nie było widoczne dla wszystkich.

DNS over HTTPS, czyli DoH, to rozwiązanie wykorzystujące protokół HTTPS do przesyłania zapytań i odpowiedzi DNS w formie zaszyfrowanej . Zamiast wysyłać czyste żądanie DNS, urządzenie hermetyzuje je w bezpiecznym połączeniu, zazwyczaj korzystając z portu 443, tego samego portu, z którego korzystają bezpieczne witryny internetowe. Chroni to zarówno zapytanie, jak i odpowiedź, uniemożliwiając ich odczytanie przez osoby trzecie.
Aby to zadziałało, serwer DNS, do którego kierowane jest zapytanie, musi również obsługiwać DNS oparty na domenie (DoH ). Samo włączenie opcji w przeglądarce nie wystarczy: wybrany resolver musi być zgodny z tym standardem. Specyfikacja ewoluuje i wciąż jest uważana za rozwijającą się technologię, chociaż od 2018 roku firmy takie jak Google i Mozilla Foundation testują ją i integrują. Oprócz poprawy prywatności, testy wskazują, że DoH może zmniejszyć opóźnienia i przyspieszyć zapytania, ponieważ nie zawsze konieczne jest rozwiązanie całej domeny, a jedynie jej minimalnej wymaganej części.
Zalety DoH: większa prywatność, mniej manipulacji i lepsza wydajność
Najbardziej oczywistą zaletą jest bezpieczeństwo. Ponieważ zapytania DNS są przesyłane w postaci zaszyfrowanej, są one znacznie trudniejsze do przechwycenia lub zmodyfikowania . Utrudnia to ataki typu man-in-the-middle, zmniejsza ryzyko narażenia na ataki w publicznych sieciach Wi-Fi i uniemożliwia lokalnemu operatorowi jednoznaczne rozpoznanie domen, których żądasz. Ponieważ ruch DoH korzysta z portu 443, miesza się z innymi połączeniami HTTPS i trudno go odróżnić od zwykłej wizyty w sieci.
Istnieją również względy wydajnościowe. DoH może zmniejszyć opóźnienia i przyspieszyć komunikację DNS dzięki zmianom w sposobie rozwiązywania nazw i lepszemu wykorzystaniu pamięci podręcznej. Na przykład metoda GET niektórych interfejsów API jest zaprojektowana tak, aby była buforowana wydajniej. W praktyce może to przełożyć się na nieco szybsze przeglądanie stron internetowych, choć nie jest to rozwiązanie idealne i poprawa nie zawsze jest zauważalna. Co więcej, ponieważ jest zaimplementowana w przeglądarce, użytkownik nie musi czekać na aktywację przez dostawcę usług internetowych.
Wady i debaty: kiedy szyfrowanie komplikuje życie
Nie wszyscy pozytywnie oceniają szyfrowanie oparte na domenach (DoH). To samo szyfrowanie, które chroni użytkownika, utrudnia również monitorowanie sieci . Wiele programów kontroli rodzicielskiej opiera się na analizie zapytań DNS w celu ustalenia, do których stron internetowych dzieci próbują uzyskać dostęp; w przypadku DoH zadanie to staje się znacznie bardziej skomplikowane, a nawet niemożliwe. Podobna sytuacja dotyczy administratorów sieci korporacyjnych, którzy tracą wgląd w domeny, których dotyczą zapytania, i nie mogą tak łatwo egzekwować pewnych reguł.
Dostawcy internetu tracą również możliwość monitorowania dostępu i blokowania określonych domen na żądanie instytucji. To wywołuje uzasadnioną debatę: niektórzy postrzegają to jako zwycięstwo w kwestii prywatności, podczas gdy inni widzą w tym problem z kontrolą i zarządzaniem . W przypadku DoT krytykuje się go również za korzystanie z własnego, rozpoznawalnego portu, który pozwala na identyfikację zapytań DNS nawet bez dokładnej wiedzy o ich treści. DoH unika tego wyraźnego sygnału, maskując się w ruchu HTTPS, ale w zamian administratorzy sieci mają mniej narzędzi do zarządzania komunikacją.
Jak włączyć DoH w przeglądarkach Chrome, Edge i Firefox

Włączenie systemu nazw domen (DNS) w nowoczesnej przeglądarce jest zazwyczaj proste, zwłaszcza jeśli jest ona oparta na Chromium lub Firefoksie. Opcja ta istnieje, choć w niektórych przypadkach jest ukryta w menu ustawień zaawansowanych . Przed wprowadzeniem jakichkolwiek zmian należy pamiętać, że przeglądarka chroni tylko własne zapytania: inne aplikacje na urządzeniu mogą nadal korzystać z innego systemu DNS, jeśli nie został on skonfigurowany na poziomie systemu.
Google Chrome
W Chrome najszybszym sposobem jest wpisanie chrome://flags/#dns-over-https na pasku adresu. Zostaniesz przeniesiony bezpośrednio do flag i funkcji eksperymentalnych przeglądarki Chrome.Zobaczysz opcję „Bezpieczne wyszukiwanie DNS”; kliknij menu rozwijane „Domyślne” i wybierz „Włączone”. Następnie musisz ponownie uruchomić przeglądarkę, aby zmiana została uwzględniona.
Microsoft Edge
W przeglądarce Edge opartej na Chromium proces ten jest praktycznie identyczny. Otwórz przeglądarkę i wpisz edge://flags/#dns-over-https w pasku wyszukiwaniaWpiszesz flagi Edge'a, a pojawi się ta sama opcja bezpiecznego wyszukiwania DNS. Zmień ustawienie domyślne na włączone i uruchom ponownie przeglądarkę, gdy pojawi się monit.
Mozilla Firefox
W przeglądarce Firefox nie musisz przechodzić do sekcji Flagi. Kliknij przycisk menu w prawym górnym rogu i wybierz Opcje . W sekcji Ogólne przewiń w dół i kliknij Ustawienia sieciowe. W otwartym oknie zaznacz pole wyboru obok opcji Włącz DNS przez HTTPS. Następnie możesz wybrać dostawców, takich jak Cloudflare i NextDNS, aby szyfrować przez HTTPS.
DNS przez TLS (DoT): inna szyfrowana ścieżka
DNS przez TLS, czyli DoT, to kolejny sposób ochrony zapytań DNS. Zamiast protokołu HTTPS, używa on protokołu TLS przez połączenie TCP i standardowy port 853. TLS opiera się na tym samym fundamencie bezpieczeństwa co HTTPS, więc idea jest podobna: stworzenie szyfrowanego tunelu, w którym tylko dwaj uczestnicy mogą odszyfrować i przetworzyć informacje. Utrudnia to ataki typu man-in-the-middle i uniemożliwia osobom trzecim odczytanie lub manipulację zapytaniem.
DotT ma swoje zalety, zwłaszcza w porównaniu z tradycyjnym DNS, który nie oferuje żadnych zabezpieczeń. Szyfrowanie uniemożliwia cyberprzestępcom przechwytywanie żądań i utrudnia stosowanie niektórych mechanizmów cenzury . Wymaga jednak kompatybilności zarówno po stronie klienta, jak i serwera. Kilku dostawców oferuje kompatybilne serwery, ale korzystanie z niego na komputerze stacjonarnym lub laptopie zazwyczaj wymaga instalacji dodatkowego oprogramowania; w nowoczesnym systemie Android, przynajmniej od wersji 9, jest ono już zintegrowane. Istnieją rozwiązania dla systemów Windows i Linux, choć nie zawsze są one tak transparentne, jak mogłoby się wydawać.
Wśród wad, wielu ekspertów ds. ochrony danych krytykuje DoT za korzystanie z jednego, rozpoznawalnego portu. Chociaż nie da się stwierdzić, do której strony internetowej następuje dostęp, możliwe jest wykrycie ruchu DNS . Dla niektórych administratorów sieci jest to przydatne, ponieważ pozwala im zachować kontrolę nad tym, co się dzieje; dla innych jest to sygnał, który wolą ukryć. Co więcej, DoT nie jest jeszcze tak rozpowszechniony jak tradycyjny DNS, a jego wykorzystanie po stronie serwera jest ograniczone. Istnieją obawy, że niektóre firmy będą coraz bardziej koncentrować zapytania DNS, potencjalnie tworząc swoisty międzynarodowy monopol.
DoH kontra DoT: Dwa sposoby ochrony tej samej rzeczy
Główna różnica między DoH a DoT leży w porcie i sposobie maskowania ruchu. DoT korzysta z własnego portu 853, podczas gdy DoH używa portu 443 i łączy się ze standardowymi połączeniami HTTPS . Ta pozornie drobna różnica wywołała ożywioną debatę. Z punktu widzenia prywatności, nieodróżnialność zapytań DNS od innego ruchu jest zaletą: jeśli nie zostaną rozpoznane, nie można nimi tak łatwo manipulować. Z punktu widzenia zarządzania siecią, utrata kontroli i utrudnione staje się wdrażanie zasad bezpieczeństwa lub filtrowania.
W istocie rzeczy, DoT opiera się na dwóch wizjach. IETF, konsorcjum opracowujące wiele standardów internetowych, stoi za DoH , natomiast Google i Mozilla Foundation zdecydowanie promują DoH. Nie są to technologie przeciwstawne, ale reprezentują różne sposoby rozumienia prywatności, widoczności sieci i roli pośredników. Wybór między nimi zależy od tego, co ma być chronione i kto musi zarządzać siecią.
DoH kontra VPN: Chroni samo pytanie, a nie całą podróż

DoH i VPN często pojawiają się w tych samych rozmowach o prywatności, ale nie robią tego samego. DoH chroni zapytanie o nazwę; VPN chroni ścieżkę, którą podążają Twoje dane . Najprościej można to zrozumieć, wyobrażając sobie DoH umieszczające wrażliwe pytanie w zapieczętowanej kopercie, podczas gdy VPN sprawia, że cała podróż przechodzi przez prywatny tunel, zanim wróci na drogę publiczną. Oba rozwiązania mogą poprawić prywatność, ale tylko jedno z nich zostało zaprojektowane tak, aby kompleksowo chronić ruch telefonów, tabletów i komputerów.
Co robi DNS przed załadowaniem witryny?
Zanim przeglądarka będzie mogła załadować stronę internetową, urządzenie musi znać jej lokalizację. DNS działa jak książka telefoniczna, tłumacząc nazwę strony internetowej na adres IP . Dzieje się to nieustannie: gdy otwierasz stronę, uruchamiasz aplikację, aktualizujesz pocztę e-mail lub odtwarzasz wideo. Zazwyczaj dzieje się to po cichu i nie zauważasz tego, co jest wygodne, ale może też łatwo to przeoczyć jako problem prywatności. Tradycyjne zapytania DNS nie są szyfrowane, więc Twój dostawca usług internetowych, Twój pracodawca, Twoja szkoła, sieć Wi-Fi kawiarni lub sieć hotelowa mogą zobaczyć, do których domen próbuje dotrzeć Twoje urządzenie. Nie widzą pełnej zawartości strony HTTPS, ale otrzymują dość szczegółowy zarys Twojej aktywności.
Zapytanie DNS nie ujawnia wszystkich przeglądanych stron ani wpisywanych danych w formularzu, ale lista domen może ujawnić nawyki, zainteresowania, narzędzia pracy, badania nad zdrowiem lub usługi finansowe . Właśnie dlatego szyfrowany DNS stał się użyteczną funkcją ochrony prywatności. Nie ujawnia wszystkiego, ale ujawnia więcej, niż wiele osób zdaje sobie sprawę.
Co ukrywa i co ujawnia DoH?
DoH wysyła zapytania DNS przez HTTPS, ten sam szyfrowany protokół, z którego korzystają bezpieczne witryny internetowe. Żądanie pozostawia urządzenie w stanie zaszyfrowanym i dociera do resolvera obsługującego standard . W publicznej sieci Wi-Fi może to utrudnić operatorowi sieci przypadkowe odczytanie zapytań. Jeśli Twój dostawca internetu zarządza DNS, przejście na resolver DoH może uniemożliwić mu dostęp do tych zapytań w standardowy sposób. Ponadto, jeśli sieć manipuluje wynikami rozpoznawania nazw, szyfrowany DNS może ograniczyć niektóre formy manipulacji.
Teraz DoH ukrywa zapytanie, a nie całą konwersację. Może to uniemożliwić niektórym obserwatorom wyraźne zobaczenie wyszukiwania domeny, ale nie zamienia całego połączenia internetowego w szyfrowany tunel . Gdy urządzenie zna adres IP, reszta połączenia podąża normalną ścieżką, chyba że inne narzędzie do ochrony prywatności zmieni tę trasę. DoH nie ukrywa Twojego prawdziwego adresu IP przed stronami internetowymi, aplikacjami ani usługami, z którymi się łączysz, ani nie sprawia, że wyglądasz, jakbyś znajdował się w innym mieście lub kraju. Jeśli zalogujesz się na konto, usługa wie, że to Ty. Jeśli przeglądarka ma pliki cookie, zapisane sesje, identyfikatory reklamowe lub rozpoznawalny odcisk palca, DoH nie usuwa tych sygnałów.
Nie chroni również każdej aplikacji, chyba że jest skonfigurowana na poziomie systemu, a aplikacja respektuje to ustawienie. Jedna przeglądarka może korzystać z bezpiecznego DNS, podczas gdy inna aplikacja na tym samym urządzeniu korzysta z innej ścieżki DNS . Niektóre aplikacje zarządzają własną siecią i nie zawsze są zgodne z ustawieniami systemu lub przeglądarki. Dlatego DoH może stwarzać fałszywe poczucie pełnej ochrony: poprawia prywatność zapytań DNS, ale nie chroni transferu plików, ruchu w wiadomościach, rozmów wideo, połączeń w grach, synchronizacji w tle ani aplikacji streamingowych w taki sposób, jak VPN.

Co chroni VPN, a czego nie może ukryć?
Sieć VPN chroni inny etap Twojej podróży. Tworzy szyfrowany tunel między Twoim urządzeniem a serwerem VPN, kierując ruch internetowy przez ten serwer . Twój dostawca usług internetowych lub lokalna sieć Wi-Fi widzi szyfrowane połączenie z serwerem VPN, a nie widzi wszystkich witryn i usług, z którymi się łączysz. Dodatkowo, sieć VPN zmienia publiczny adres IP widoczny dla stron internetowych i aplikacji: zamiast adresu IP Twojego domu lub operatora komórkowego, miejsce docelowe widzi adres IP serwera VPN. Może to ograniczyć śledzenie oparte na lokalizacji, pomóc w ominięciu profili niektórych dostawców usług internetowych i zwiększyć bezpieczeństwo korzystania z publicznej sieci Wi-Fi.
Kompleksowa sieć VPN może chronić przeglądarki, aplikacje do streamingu, klientów poczty e-mail, narzędzia do tworzenia kopii zapasowych w chmurze, aplikacje do przesyłania wiadomości, gry i usługi działające w tle. Po odpowiedniej konfiguracji może również kierować żądania DNS przez szyfrowany tunel , dlatego warto przeprowadzić test szczelności DNS. Należy jednak pamiętać, że VPN to nie magia. Jeśli zalogujesz się do sieci społecznościowej, konta e-mail, serwisu streamingowego lub sklepu internetowego, usługa ta nadal będzie Cię znać. Może ukryć Twój oryginalny adres IP, ale nie anonimizuje Twojego logowania. To samo dotyczy wszystkiego, co wysyłasz bezpośrednio: Twojego imienia i nazwiska, adresu e-mail, danych płatności, adresu wysyłki, zdjęć czy wiadomości.
Pliki cookie i odcisk palca przeglądarki nadal mają znaczenie. Aplikacje mogą stwarzać podobne problemy poprzez identyfikatory reklam, uprawnienia, dostęp do lokalizacji, skanowanie Bluetooth, nazwy pobliskich sieci Wi-Fi i narzędzia skanujące. Złośliwe oprogramowanie to kolejna trudna przeszkoda, ponieważ może przechwycić dane, zanim dotrą one do tunelu VPN . Krótko mówiąc, VPN ukrywa i szyfruje wiele aktywności, ale nie maskuje każdego cyfrowego odcisku palca.
DoH i VPN można używać jednocześnie
Tak, można je łączyć, ale idealna konfiguracja zależy od tego, jak urządzenie, przeglądarka i aplikacja VPN obsługują DNS. W wielu przypadkach najprostszym rozwiązaniem jest pozostawienie obsługi DNS przez VPN . Dobra aplikacja powinna wysyłać zapytania DNS przez szyfrowany tunel, aby Twój dostawca usług internetowych nie otrzymywał ich bezpośrednio. W ten sposób zyskujesz prywatność DNS w ramach połączenia VPN bez konieczności oddzielnej zmiany ustawień przeglądarki.
Problem pojawia się, gdy przeglądarka korzysta z własnej konfiguracji Domain Authority (DoH), podczas gdy VPN próbuje zarządzać DNS na poziomie systemu. Nic nie może się zepsuć, ale pojawia się zamieszanie : możesz myśleć, że wszystkie zapytania przechodzą przez VPN, ale w rzeczywistości przeglądarka wysyła niektóre z nich samodzielnie do innego resolvera. W tym miejscu z pomocą przychodzi test szczelności DNS. Jeśli po połączeniu z VPN widzisz serwery DNS swojego dostawcy usług internetowych, coś nie działa zgodnie z oczekiwaniami; jeśli widzisz serwery powiązane z VPN, konfiguracja najprawdopodobniej działa poprawnie.
Kiedy DoH jest wystarczające, a kiedy zaleca się użycie VPN?
DoH może być wystarczające, gdy priorytetem jest podstawowa prywatność zapytań DNS w przeglądarce. W zaufanej sieci domowej włączenie funkcji Secure DNS zmniejsza ryzyko naruszenia jawnego tekstu bez konieczności zmiany lokalizacji lub zabezpieczania wszystkich aplikacji . Jest to również przydatne w sieciach, w których filtrowanie lub manipulacja DNS stanowi problem, ponieważ przesyłanie danych przez HTTPS utrudnia łatwą inspekcję lub modyfikację. Nie oznacza to, że omija ona wszystkie ograniczenia lub jest odporna na cenzurę, ale stanowi znaczną poprawę w porównaniu z niezaszyfrowanym DNS. Co więcej, jest lekka: nie wymaga wyboru serwera VPN ani znaczącej zmiany routingu, a zazwyczaj nie zauważysz znaczącego wpływu na szybkość.
VPN jest najbardziej sensowny, gdy zależy Ci na ochronie całego urządzenia, a nie tylko na wyszukiwaniu DNS. Dotyczy to lotnisk, hoteli, szkół, przestrzeni coworkingowych, kawiarni i wynajmowanych kwater . W sieciach współdzielonych nie wiesz, kto kontroluje router, kto jeszcze jest podłączony ani czy ktoś próbuje przechwytywać ruch. VPN pomaga również, gdy nie chcesz, aby Twój dostawca usług internetowych tworzył profil Twoich wzorców przeglądania: mimo że protokół HTTPS chroni zawartość stron, metadane sieciowe nadal mogą ujawniać użyteczne wzorce. Podróżowanie to kolejny wyraźny przykład: VPN może zwiększyć spójność połączenia, chronić Cię w nieznanych sieciach i sprawić, że strony internetowe będą widzieć lokalizację serwera VPN zamiast Twojego tymczasowego połączenia lokalnego.
Szczegóły techniczne interfejsów API DoH usługi Google Public DNS
Usługa Google Public DNS oferuje dwa różne interfejsy API DoH. Jeden z nich jest zgodny ze standardem RFC 8484 i akceptuje żądania GET i POST pod adresem https://dns.google/dns-query, a drugi to interfejs API JSON, który obsługuje wyłącznie żądania GET pod adresem https://dns.google/resolve . Dostępny jest również interfejs internetowy pod adresem https://dns.google/, który wyświetla wyniki JSON w przeglądarce, ale nie implementuje on pełnego interfejsu API. Interfejsu tego nie należy mylić z adresami URL interfejsu API ani z adresem https://dns.google/query. Usługa nie obsługuje niezabezpieczonych adresów URL HTTP, a DoH jest również obsługiwany przez publiczną usługę DNS64 firmy Google, chociaż w tym przypadku obsługiwany jest tylko protokół IPv6. Dokumentacja bezpiecznego transportu firmy Google zawiera przykłady użycia curl oraz szczegółowe informacje na temat protokołów TLS, DoT i DoH.
Dostępne metody HTTP
Metoda GET może zmniejszyć opóźnienie, ponieważ buforuje efektywniej. Żądania GET zgodne z RFC 8484 muszą zawierać parametr `?dns=` z komunikatem DNS zakodowanym w Base64Url i jest to jedyna metoda obsługiwana przez API JSON. Metoda POST jest również dostępna tylko w RFC 8484 i używa binarnego komunikatu DNS z `application/dns-message` zarówno w treści żądania, jak i odpowiedzi. Metoda HEAD nie jest obecnie obsługiwana i zwraca błąd 400 Bad Request. Pozostałe metody zwracają błędy 501 Not Implemented.
Kody statusu i błędy
Interfejs API zwraca kilka kodów HTTP, które warto znać. Kod 200 OK oznacza, że parsowanie HTTP i komunikacja z resolverem DNS zakończyły się powodzeniem ; treść odpowiedzi może być binarną odpowiedzią DNS lub JSON, w zależności od punktu końcowego, nagłówka Accept i parametrów GET. Uwaga: błąd HTTP może być również błędem DNS, dlatego zaleca się sprawdzenie kodu odpowiedzi DNS, na przykład pola „Status” w JSON, pod kątem błędów takich jak SERVFAIL, FORMERR, REFUSED lub NOTIMP.
- 301 Przeniesiono na stałe: Klient musi ponowić żądanie pod adresem URL określonym w polu Lokalizacja. Jeśli pierwotne żądanie było POST, powinno zostać ponowiona próba z użyciem GET tylko wtedy, gdy nowy adres URL określa parametr DNS; w przeciwnym razie należy powtórzyć żądanie z użyciem POST. Mogą również pojawić się kody stanu 302, 307 i 308, a klienci DoH muszą obsłużyć wszystkie cztery. Stałe kody stanu 301 i 308 mogą być buforowane w nieskończoność. Żądania POST, które otrzymują kod stanu 307 lub 308, muszą być zawsze ponawiane z użyciem POST.
- 400 Błędnych żądań: Problemy z analizą parametrów GET lub nieprawidłowy komunikat żądania DNS. Większość nieprawidłowych komunikatów DNS otrzymuje błąd 200 OK z FORMERR, ale błędy HTTP występują w przypadku nieczytelnych komunikatów bez sekcji „Pytanie”, z kodem QR oznaczającym odpowiedź lub z bezsensownymi kombinacjami kodów.
- 413 Ładunek jest za duży: Treść żądania POST RFC 8484 przekracza maksymalny rozmiar wiadomości wynoszący 512 bajtów.
- 414 Zbyt długi URI: Nagłówek zapytania GET był zbyt duży lub parametr dns przekroczył 512 bajtów.
- 415 Nieobsługiwany typ nośnika: Treść POST nie miała nagłówka o typie zawartości application/dns-message.
- 429 Zbyt wiele żądań: W danym okresie wysłano zbyt wiele żądań. Klient musi czekać do czasu określonego w nagłówku Retry-After.
- 500 wewnętrzny błąd serwera: Błędy wewnętrzne w usłudze DoH.
- 501 Nie wdrożono: Zaimplementowano tylko metody GET i POST; pozostałe zwracają ten błąd.
- 502 Zła brama: Usługa DoH nie mogła nawiązać komunikacji z publicznymi resolwerami DNS Google. Wypróbowanie innego adresu może pomóc, ale skuteczniejszym planem awaryjnym jest wypróbowanie innej usługi DoH lub przełączenie się na tradycyjny DNS z użyciem protokołu UDP lub TCP pod adresem 8.8.8.8.
Najlepsze praktyki dotyczące prywatności i wydajności
Twórcy aplikacji DoH powinni ograniczyć liczbę nagłówków HTTP. Nagłówki takie jak Cookie, User-Agent i Accept-Language mogą ujawniać informacje o implementacji klienta i przyczyniać się do deanonimizacji . Zaleca się wysyłanie tylko nagłówków niezbędnych dla DoH: Host, Content-Type (dla żądań POST) oraz, w razie potrzeby, Accept. Nagłówek User-Agent powinien być uwzględniony w wersjach rozwojowych i testowych. Zaleca się również korzystanie z opcji uzupełniania EDNS w celu skrócenia zapytań do standardowej długości i utrudnienia analizy ruchu. Uzupełnianie HTTP/2 jest możliwe, ale w przeciwieństwie do uzupełniania EDNS nie generuje ono uzupełnień w odpowiedziach serwera DoH.
Metoda POST opisana w dokumencie RFC 8484 powinna być używana wyłącznie w aplikacjach lub trybach przeglądarki wymagających ochrony prywatności. Korzystanie z metody POST zmniejsza pojemność pamięci podręcznej i może zwiększyć opóźnienie, dlatego generalnie nie jest zalecana . Zmniejszenie rozmiaru pamięci podręcznej może być jednak wskazane w przypadku aplikacji, które chcą zapobiegać atakom na synchronizację aplikacji internetowych, mającym na celu odkrycie domen, które użytkownik ostatnio odwiedził. Podejście HTTPS ma również praktyczne zalety: interfejsy API HTTPS są szeroko dostępne i obsługiwane, co upraszcza implementację; usługa HTTPS zapewnia aplikacjom internetowym dostęp do wszystkich typów rekordów DNS, omijając ograniczenia interfejsów API przeglądarek lub systemów operacyjnych, które zazwyczaj ograniczają się do wyszukiwania typu host-adres; a klienci implementujący protokół HTTPS przez protokół UDP z protokołem QUIC mogą uniknąć problemów, takich jak blokowanie nagłówka wiersza występujące w protokole TCP. Jeśli napotkasz błąd lub chcesz poprosić o nową funkcję, zgłoś problem związany z protokołem DoH za pośrednictwem standardowych kanałów.
Często zadawane pytania dotyczące DoH i VPN
Jednym z najczęściej zadawanych pytań jest to, czy ma sens korzystanie z DoH, gdy już korzystasz z VPN. Jest to możliwe, ale najpraktyczniejszym podejściem jest zazwyczaj pozostawienie VPN obsłudze DNS i sprawdzenie za pomocą testu szczelności, czy zapytania przechodzą przez właściwe kanały. Jeśli przeglądarka wysyła własne zapytania w jedną stronę, a VPN w drugą, może Cię czekać niemiła niespodzianka.
Kolejnym częstym pytaniem jest, czy DoH uniemożliwia Twojemu dostawcy internetu podgląd odwiedzanych przez Ciebie stron. DoH ukrywa zapytania DNS przed wieloma obserwatorami, ale nie usuwa wszystkich metadanych ani nie ukrywa Twojego adresu IP : Twój dostawca internetu nadal może zobaczyć, z którymi adresami IP się łączysz, oraz inne informacje sieciowe. Aby zapewnić szerszą ochronę, potrzebujesz VPN lub kombinacji kilku warstw prywatności.
Warto również zapytać, czy protokół DomainHost (DoH) jest wystarczający w publicznych sieciach Wi-Fi. Może on pomóc uniemożliwić operatorowi sieci łatwe odczytanie zapytań DNS, ale nie chroni całego połączenia ani ruchu wszystkich aplikacji . Na lotniskach, w hotelach i kawiarniach korzystanie z VPN jest zazwyczaj bardziej kompleksowe, zwłaszcza jeśli nie wiesz, kto kontroluje router lub czy inne osoby są połączone.
System nazw domen (DoH) i sieci VPN nie są bezpośrednimi rywalami, a raczej narzędziami o różnych możliwościach. DoH szyfruje wyszukiwanie domeny i ogranicza narażenie na ataki podczas tego procesu; VPN szyfruje ścieżkę między urządzeniem a serwerem i zmienia adres IP widoczny dla odbiorców . Żadna z tych metod nie czyni Cię niewidzialnym: konta, pliki cookie, odciski palców przeglądarki, uprawnienia aplikacji, złośliwe oprogramowanie i wszelkie dane, którymi dzielisz się bezpośrednio, nadal mogą Cię zidentyfikować. Nie oznacza to jednak, że są bezużyteczne. Oznacza to po prostu, że każda z nich ma swoją rolę. DoH chroni wyszukiwanie adresów; VPN chroni znacznie większą część ścieżki, którą pokonują Twoje dane.