Jak skonfigurować DNS over HTTPS w przeglądarce i w systemie

Co zmienia DNS over HTTPS w praktycznym użytku

Krótkie przypomnienie: jak działa klasyczny DNS

DNS to książka telefoniczna internetu. Gdy wpisujesz w przeglądarce nazwę domeny, system musi odnaleźć odpowiadający jej adres IP. Robi to właśnie przez serwer DNS – wysyła zapytanie typu „jaki jest adres IP dla example.com?” i czeka na odpowiedź.

W tradycyjnym wariancie zapytania DNS:

• są wysyłane zwykle po UDP (czasem TCP) na port 53,
• nie są szyfrowane, więc treść zapytania leci „otwartym tekstem”,
• idą do serwera DNS skonfigurowanego w systemie (zwykle od ISP lub z routera).

Po drodze to zapytanie przechodzi przez różne urządzenia sieciowe: router domowy, sprzęt operatora internetowego, ewentualnie firmowe firewalle czy systemy filtrujące. Każdy punkt pośredni, który ma dostęp do surowego ruchu, może zobaczyć, do jakiej domeny wysyłane jest zapytanie DNS.

Gdzie w klasycznym DNS dochodzi do podsłuchu i manipulacji

Zwykły DNS jest czytelny jak pocztówka. Operator sieci:

• widzi, jakie domeny odwiedzasz (po zapytaniach DNS),
• może logować ten ruch i profilować użytkownika,
• może blokować domeny (cenzura, kontrola rodzicielska, firmowe polityki).

Podobnie zachowują się publiczne hotspoty w kawiarniach czy hotelach. Administrator takiej sieci ma możliwość:

• podmiany odpowiedzi DNS (np. przekierowania na stronę z reklamą lub phishingiem),
• zastosowania filtrów na poziomie DNS (blokada konkretnych stron),
• analizowania historii odwiedzanych domen użytkowników.

Do tego dochodzi klasyczny spoofing DNS – atakujący podmienia odpowiedź DNS i zamiast prawdziwego IP serwera banku czy poczty dostarczany jest adres fałszywy. Jeżeli użytkownik nie sprawdzi dokładnie certyfikatu HTTPS (a zwykle nie sprawdza), szansa na skuteczne oszustwo rośnie.

DNS over HTTPS – kapsułkowanie zapytań w szyfrowany kanał

DNS over HTTPS (DoH) działa na prostym pomyśle: zamiast wysyłać zapytania DNS w otwartym protokole na porcie 53, są one pakowane do żądań HTTPS i wysyłane na port 443 – taki sam, jak zwykłe szyfrowane strony WWW.

Co to daje w praktyce:

• zapytanie DNS jest częścią zaszyfrowanego połączenia TLS,
• dla osób po drodze wygląda po prostu jak zwykły ruch HTTPS do konkretnego serwera,
• treść zapytania (konkretna domena) jest ukryta przed hotspotem, operatorem itd.

Mit: DoH robi z użytkownika „niewidzialnego ducha” w sieci. Rzeczywistość: DoH jedynie szyfruje warstwę DNS. Cała reszta – połączenia TCP/IP, adresy IP odwiedzanych serwerów, fingerprinting przeglądarki, cookies – nadal istnieje i nadal jest widoczna dla wielu podmiotów.

Korzyści z włączenia DNS over HTTPS

Najważniejsze praktyczne zalety DoH:

• Utrudnienie podsłuchu DNS – lokalna sieć, hotspot czy operator nie widzą domyślnie treści zapytań DNS, jedynie ruch do konkretnego dostawcy DoH.
• Utrudnienie manipulacji odpowiedziami DNS – odpowiedzi dostarczane są przez zaufany resolver, więc przechwycenie i podmiana na poziomie lokalnej sieci staje się dużo trudniejsza.
• Ominięcie filtrów DNS w sieci – wiele form cenzury czy kontroli rodzicielskiej opiera się wyłącznie na blokadzie DNS; DoH do zewnętrznego dostawcy zwykle to omija.
• Często lepsze wsparcie dla DNSSEC i filtrów antyphishingowych – profesjonalni dostawcy DoH dodają własne mechanizmy ochronne.

Dla użytkownika prywatnego oznacza to zwiększenie prywatności przed operatorem oraz mniejszą podatność na prymitywne formy ataków typu spoofing DNS w publicznych sieciach.

Ograniczenia i typowe nieporozumienia

DoH nie jest uniwersalnym lekarstwem na śledzenie w sieci. Po włączeniu DoH:

• operator nadal widzi, z jakimi adresami IP się łączysz,
• serwisy internetowe dalej rozpoznają cię po cookies, identyfikatorach, logowaniu,
• dostawca DoH staje się nowym zaufanym punktem, który widzi twoje zapytania DNS.

Mit: „Dostawca bez logów nic o tobie nie wie”. W praktyce prawie każdy operator musi zbierać chociaż minimalne logi operacyjne: obciążenie serwerów, statystyki zużycia, często zagregowane, ale nadal istniejące. Różnica polega na tym, czy z tych logów da się odtworzyć historię konkretnych użytkowników, czy są one zanonimizowane i kasowane po krótkim czasie.

DoH jest więc jednym z klocków w budowaniu prywatności. Bez sensownej konfiguracji przeglądarki, sensownego doboru dostawcy i podstaw higieny cyfrowej korzyści będą ograniczone.

Kiedy opłaca się włączać DNS over HTTPS

Publiczne sieci Wi‑Fi – hotele, kawiarnie, lotniska

DoH najwięcej daje w sieciach, nad którymi nie masz kontroli. Podłączając się do publicznego Wi‑Fi:

• nie wiesz, kto jest administratorem i jakie ma intencje,
• sprzęt po drodze może wstrzykiwać reklamy, strony ostrzegawcze czy komunikaty powitalne,
• łatwiej też stworzyć złośliwy hotspot podszywający się pod prawdziwy.

W takiej sytuacji klasyczny DNS pozwala administratorowi (lub atakującemu) podsłuchiwać ruch i manipulować nim. Włączenie DoH na poziomie przeglądarki mocno to utrudnia, bo zapytania DNS idą zaszyfrowane do zaufanego dostawcy, a nie do serwera wskazanego przez hotspot.

Dobrym nawykiem jest połączenie DoH z:

• VPN-em (szyfrowany tunel całego ruchu),
• aktualną przeglądarką i sprawdzaniem certyfikatów HTTPS w wrażliwych serwisach.

Sieć domowa – prywatność przed ISP i konflikt z filtrami

W domu sytuacja jest inna. Zwykle to ty kontrolujesz router, a domyślny DNS pochodzi od operatora. Zmiana na DoH w przeglądarce lub systemie:

• ogranicza możliwość profilowania ruchu przez ISP na poziomie DNS,
• może kolidować z wbudowaną w router filtracją (kontrola rodzicielska, blokady kategorii stron),
• czasem powoduje bałagan, gdy część urządzeń używa filtrującego DNS w routerze, a część wszystko omija dzięki DoH.

Jeżeli ktoś wykorzystuje DNS w routerze do blokowania szkodliwych treści dla dzieci, ślepe włączenie DoH w przeglądarce dziecka zwykle obchodzi te zabezpieczenia. Z perspektywy bezpieczeństwa rodzinnego bywa to problemem większym niż zysk prywatności przed operatorem.

W sieci domowej DoH ma najwięcej sensu, gdy:

• sam świadomie wybierasz zewnętrznego dostawcę DoH/DoT (z jasną polityką prywatności),
• konfigurujesz go konsekwentnie – albo w routerze, albo w systemach / przeglądarkach,
• wiesz, jak zmienia to działanie lokalnych filtrów i list blokujących.

Sieci firmowe – kiedy DoH bywa wręcz niewskazany

W środowisku firmowym do gry wchodzą polityki bezpieczeństwa, audyt i wymagania compliance. Administratorzy zazwyczaj:

• stosują centralne serwery DNS z logami do celów bezpieczeństwa,
• blokują złośliwe domeny, phishing, malware na poziomie DNS,
• kontrolują, dokąd mogą wychodzić firmowe komputery.

Włączenie DoH „na dziko” w przeglądarce służbowego komputera potrafi:

• ominąć firmowe filtry bezpieczeństwa,
• utrudnić reagowanie na incydenty (brak logów DNS w systemach SIEM),
• naruszyć politykę bezpieczeństwa i wewnętrzne regulaminy.

Dlatego wiele firm:

• blokuje DoH na firewallu (np. przez SNI/ESNI lub listy znanych endpointów DoH),
• stosuje własne serwery DoT/DoH i wymusza korzystanie z nich,
• określa wprost w politykach, czy DoH jest dopuszczalne, czy zabronione.

Jeśli komputer jest służbowy, a sieć zarządzana centralnie, eksperymenty z DoH rób tylko w uzgodnieniu z działem IT.

Czy DNS over HTTPS przyspiesza internet

Mit: „DoH przyspieszy internet, bo jest nowoczesny”. W praktyce:

• czas odpowiedzi DNS zależy od lokalizacji i wydajności serwera, nie od samego protokołu,
• szyfrowanie wprowadza minimalny narzut, ale na nowoczesnym sprzęcie jest on znikomy,
• dobre publiczne resolvery (z CDNami) bywają szybsze niż stare, źle skonfigurowane serwery ISP.

Realny scenariusz: po przejściu na DoH do dużego dostawcy, który ma serwery blisko ciebie, pierwsze otwarcie nowych domen może delikatnie przyspieszyć. W innych przypadkach różnica będzie niezauważalna, a czasem nawet otrzymasz minimalnie wolniejsze odpowiedzi z powodu dystansu do serwera DoH lub dodatkowej logiki filtrującej.

DoH jest funkcją przede wszystkim prywatnościowo‑bezpieczeństwową. Ewentualne przyspieszenie traktuj jako dodatek, nie główny cel.

Prywatność przed operatorem a prywatność przed serwisami online

Włączenie DoH zmniejsza wiedzę twojego operatora i lokalnej sieci o odwiedzanych domenach. Nie zmienia to jednak relacji z serwisami, z których korzystasz:

• Google, Facebook, bank, poczta – widzą cię tak samo jak wcześniej,
• adresy IP serwerów, do których się łączysz, nadal są widoczne na poziomie sieci,
• śledzenie przez cookies, piksele, fingerprinting przeglądarki pozostaje bez zmian.

DoH poprawia prywatność warstwy DNS. Jeśli celem jest szersza ochrona prywatności, trzeba łączyć to z:

• ograniczaniem śledzących skryptów (uBlock Origin, Privacy Badger itd.),
• sensownym doborem przeglądarki i jej ustawień prywatności,
• rozsądnym podejściem do logowania się w wielu serwisach i udostępniania danych.

Jak wybrać dostawcę DNS over HTTPS

Na co patrzeć w polityce prywatności DNS

Zmieniasz tylko to, kto widzi twoje zapytania DNS. Zamiast operatora i lokalnej sieci głównym obserwatorem staje się dostawca DoH. Wybór nie powinien być przypadkowy.

W politykach prywatności i opisach usług warto szukać odpowiedzi na kilka pytań:

• Czy logowane są adresy IP użytkowników, a jeśli tak – jak długo?
• Czy dostawca tworzy profile użytkowników / urządzeń na podstawie zapytań DNS?
• Czy dane są wykorzystywane do reklam lub udostępniane podmiotom trzecim?
• Jak długo przechowywane są logi – minuty, dni, miesiące?
• Czy dane są wykorzystywane wyłącznie w celach bezpieczeństwa i analityki zbiorczej?

Formuły marketingowe typu „no logs” bywają skrótem myślowym. Zwykle chodzi o brak trwałych logów umożliwiających identyfikację konkretnych użytkowników, ale drobne logi operacyjne (np. do monitoringu wydajności) i tak istnieją.

Kluczowe kryteria: jurysdykcja, DNSSEC, DoH vs DoT

Przy wyborze dostawcy DNS over HTTPS dobrze uwzględnić:

• Jurysdykcję – kraj, w którym zarejestrowana jest firma i w którym fizycznie stoją główne serwery. Wpływa to na możliwe obowiązki prawne (np. nakazy wydania logów).
• Politykę logowania – czy deklarowana jest minimalizacja danych, czy wręcz zbieranie danych do celów marketingowych.
• Obsługę DNSSEC – mechanizm kryptograficzny chroniący przed podmianą odpowiedzi DNS na wyższych poziomach (poza lokalną siecią).
• Wsparcie DoH i DoT – DNS over TLS (DoT) to alternatywny protokół szyfrowania DNS na porcie 853. Ważny, jeśli chcesz używać szyfrowanego DNS nie tylko przez HTTPS.
• Dodatkowe funkcje – filtrowanie złośliwych domen, blokowanie treści dla dorosłych, blokowanie reklam i trackerów.

Przykładowi dostawcy DNS over HTTPS i ich cechy

Kilku popularnych dostawców, którzy wspierają DoH, różni się podejściem do prywatności i dodatkowymi funkcjami. Przykładowe porównanie:

Porównanie kilku popularnych usług DoH

Kilka często wybieranych usług DoH, w dużym skrócie:

• Cloudflare (1.1.1.1) – nacisk na prywatność, krótkie przechowywanie logów (bez długotrwałych logów IP w domyślnej wersji), obsługa DNSSEC. Dostępne profile: podstawowy, filtrujący malware, filtrujący malware + treści dla dorosłych.
• NextDNS – bardziej „szwajcarski scyzoryk” DNS: rozbudowane filtry, statystyki, własne listy blokad, możliwość niemal całkowitego wyłączenia logowania lub trzymania logów przez ograniczony czas.
• Quad9 – mocny nacisk na bezpieczeństwo (blokowanie złośliwych domen), fundacja non-profit, inna jurysdykcja niż giganty z USA, obsługa DNSSEC. Profil zbliżony raczej do ochrony przed malware niż maksymalnej anonimowości.
• Google Public DNS – stabilny i bardzo szybki, ale część osób ma rezerwę ze względu na model biznesowy Google. Polityka prywatności technicznie przejrzysta, lecz pytanie brzmi: czy chcesz powierzać kolejną warstwę ruchu temu samemu gigantowi?

Mit bywa taki, że „każdy publiczny DNS jest anonimowy”. W rzeczywistości każdy operator musi w jakimś zakresie monitorować infrastrukturę – z perspektywy prywatności liczy się skala i czas retencji danych oraz to, czy dane wiązane są z konkretnymi profilami użytkowników.

Adresy endpointów DoH – co będzie potrzebne w konfiguracji

Do konfiguracji w przeglądarce lub systemie przydają się konkretne adresy URL. Kilka typowych przykładów (mogą się zmieniać, więc przy kluczowych wdrożeniach zawsze zaglądaj do aktualnej dokumentacji dostawcy):

• Cloudflare (podstawowy): https://cloudflare-dns.com/dns-query
• Cloudflare Malware Blocking: https://security.cloudflare-dns.com/dns-query
• Cloudflare Family (malware + treści dla dorosłych): https://family.cloudflare-dns.com/dns-query
• NextDNS: indywidualny adres w formacie https://dns.nextdns.io/<Twój-ID>
• Quad9 (przykładowy endpoint): https://dns.quad9.net/dns-query
• Google Public DNS: https://dns.google/dns-query

Częsta pułapka: w sieciach firmowych część z tych endpointów bywa blokowana, więc sama poprawna konfiguracja w przeglądarce nie oznacza jeszcze, że zapytania rzeczywiście idą DoH.

Konfiguracja DNS over HTTPS w Firefox – od podstaw do zaawansowanych opcji

Włączenie DoH w ustawieniach podstawowych

Firefox od dawna ma DoH wbudowany. Najprostsza ścieżka, bez dotykania ukrytych opcji:

1. Otwórz menu (trzy kreski w prawym górnym rogu) i wybierz Ustawienia.
2. Przejdź do sekcji Prywatność i bezpieczeństwo.
3. Przewiń na dół do części Ustawienia sieci i kliknij Ustawienia….
4. Na dole okna zaznacz Włącz DNS przez HTTPS.
5. W polu Usługa wybierz:
   • jednego z predefiniowanych dostawców (najczęściej Cloudflare, czasem inne, zależnie od regionu), albo
   • Inny i wklej adres URL endpointu DoH, jeśli korzystasz z mniej standardowej usługi lub własnego serwera.
6. Zatwierdź ustawienia przyciskiem OK.

Od tej chwili Firefox będzie próbował używać DoH dla wszystkich zapytań DNS wykonywanych na potrzeby przeglądania stron – niezależnie od tego, jaki DNS jest ustawiony w systemie czy routerze (z zastrzeżeniami opisywanymi dalej).

Tryb „wyłącznie DoH” kontra tryb hybrydowy

Po włączeniu DoH Firefox może działać w dwóch głównych trybach:

• Tryb domyślny (hybrydowy) – przeglądarka używa DoH, ale potrafi wrócić do systemowego DNS, gdy DoH nie działa lub gdy określone wyjątki temu sprzyjają (np. wykryta sieć firmowa).
• Tryb wymuszonego DoH – wszystkie zapytania DNS idą przez DoH, a jeśli endpoint nie odpowiada, część domen przestanie się rozwiązywać (do czasu naprawy).

Jeśli zależy ci na maksymalnej spójności i nie chcesz, żeby cokolwiek „bokiem” poszło przez klasyczny DNS, trzeba wejść głębiej w konfigurację:

1. W pasku adresu wpisz about:config i zaakceptuj ostrzeżenie.
2. Znajdź klucz network.trr.mode.
3. Ustaw:
   • 2 – preferuj DoH (TRR), ale w razie problemów użyj klasycznego DNS,
   • 3 – tylko DoH (TRR), systemowy DNS pomijany.

Mit jest taki, że „najbezpieczniejszy jest zawsze tryb tylko DoH”. W praktyce, jeśli endpoint DoH padnie, możesz nagle „stracić internet” w tej jednej przeglądarce, podczas gdy inne aplikacje działają normalnie. Dla wielu użytkowników tryb 2 (preferuj DoH) jest rozsądniejszym kompromisem.

Zaawansowane parametry Firefox TRR

Firefox implementuje DoH w ramach modułu TRR (Trusted Recursive Resolver). Kilka kluczowych opcji z about:config:

• network.trr.uri – adres endpointu DoH (np. https://cloudflare-dns.com/dns-query). Tu wklejasz dokładny URL wybranego dostawcy.
• network.trr.bootstrapAddress – opcjonalny adres IP, z którego Firefox skorzysta, aby rozwiązać nazwę hosta w network.trr.uri. Przydaje się, gdy nie chcesz, by pierwsze zapytanie do endpointu poszło przez zwykły DNS (np. wpisujesz tu 1.1.1.1 dla Cloudflare).
• network.trr.custom_uri – alternatywny endpoint DoH, wykorzystywany, gdy używasz opcji „Inny” w ustawieniach graficznych.
• network.trr.confirmationNS – domena używana do potwierdzenia, że DoH działa (domyślnie własna domena Mozilli). Można to zmienić, jeśli korzystasz z niestandardowej infrastruktury i chcesz mieć pełną kontrolę nad procesem potwierdzania.
• network.trr.excluded-domains – lista domen rozwiązywanych zawsze przez klasyczny DNS, rozdzielonych przecinkami. Dobre miejsce, by wpisać domeny wewnętrzne firmy lub specyficzne usługi lokalne.

Praktyczny przykład: w domowej sieci korzystasz z lokalnej domeny nas.lan na serwer plików. Po włączeniu DoH nagle przestaje się ona rozwiązywać. Dodanie nas.lan do network.trr.excluded-domains rozwiązuje problem – reszta domen idzie DoH, a lokalna nazwa wciąż korzysta z DNS w routerze.

Wyjątki i integracja z sieciami firmowymi

Firefox posiada mechanizm tzw. „canary domain” i wykrywania sieci, w których DoH jest niepożądany (np. z powodów korporacyjnych). W części krajów i konfiguracji domyślnej:

• Firefox wyłącza DoH, jeśli wykryje, że system korzysta z DNS filtrującego lub urządzenia zabezpieczającego,
• administratorzy mogą dodać specyficzne domeny lub rekordy TXT informujące przeglądarkę, aby nie używać DoH w danej sieci.

Jeśli korzystasz z komputera firmowego i mimo wszystko próbujesz wymusić DoH na poziomie about:config, często przegrasz z polityką grupową lub filtrowaniem na firewallu. Warto to potraktować jako sygnał, że sieć ma swoje zasady, a nie jako „usterkę Firefoksa”.

Konfiguracja DNS over HTTPS w Chrome, Edge i innych przeglądarkach Chromium

Podstawowe włączenie DoH w Chrome

Nowsze wersje Chrome (oraz większość przeglądarek opartych na Chromium) mają opcję DoH w ustawieniach prywatności. W Chrome stabilnym ścieżka wygląda następująco:

1. Kliknij trzy kropki w prawym górnym rogu i wybierz Ustawienia.
2. Przejdź do sekcji Prywatność i bezpieczeństwo.
3. Wejdź w Bezpieczeństwo.
4. Odszukaj opcję Użyj bezpiecznego DNS i włącz przełącznik.
5. Wybierz:
   • Użyj dostawcy bieżącej usługi – Chrome spróbuje automatycznie używać DoH, jeśli aktualny DNS w systemie je wspiera, lub
   • Wybierz innego dostawcę – lista typowych usług (Google, Cloudflare, OpenDNS, CleanBrowsing itd.) oraz możliwość wpisania własnego URL w opcji „Dostosowany”.

Mit: „jeśli włączę bezpieczny DNS w Chrome, to cały system będzie używał DoH”. Rzeczywistość jest taka, że to ustawienie dotyczy tylko zapytań wykonywanych przez samą przeglądarkę – inne aplikacje dalej korzystają z tego, co ustawione jest w systemie.

Edge, Brave, Vivaldi – gdzie szukać opcji DoH

Przeglądarki oparte na Chromium dziedziczą ten sam mechanizm, ale różnie chowają go w interfejsie:

• Microsoft Edge – otwórz Ustawienia → Prywatność, wyszukiwanie i usługi → sekcja Bezpieczeństwo → Używaj bezpiecznego DNS. Dalej analogicznie: włączasz opcję i wybierasz dostawcę lub własny URL DoH.
• Brave – Settings → Privacy and security → Security → „Use secure DNS”. Brave czasem dodaje własne opcje związane z prywatnością, ale logika DoH pozostaje podobna do Chrome.
• Vivaldi – Settings → Privacy → sekcja Secure DNS. Można zarówno wybrać gotowego dostawcę, jak i wprowadzić własny endpoint.

W niektórych dystrybucjach firmowych lub na systemach zarządzanych centralnie te opcje mogą być wyszarzone. Oznacza to, że administrator wymusił politykę (np. przez Active Directory / GPO) i przeglądarka ma korzystać wyłącznie z określonego resolvera lub z klasycznego DNS.

Różnice w zachowaniu DoH w Chromium

Chromium i jego „klony” stosują nieco inną filozofię niż Firefox:

• domyślnie próbują użyć DoH z tym samym dostawcą, którego masz ustawionego w systemie (jeśli dostawca wspiera DoH),
• jeśli DNS w systemie nie ma obsługi DoH, a ty nie wskażesz innego resolvera w ustawieniach, część zapytań dalej będzie szła klasycznym, nieszyfrowanym kanałem,
• nie mają tak rozbudowanego mechanizmu TRR jak Firefox – stawiają raczej na integrację z istniejącą infrastrukturą DNS niż na całkowite oderwanie się od niej.

W praktyce oznacza to, że jeśli chcesz mieć pełną kontrolę nad tym, do kogo idą zapytania DNS z Chrome, najlepiej jawnie wskazać konkretnego dostawcę i jego endpoint DoH, zamiast liczyć na tryb „automatyczny”.

Własny endpoint DoH w Chrome/Edge

Jeśli korzystasz z usługi typu NextDNS lub własnego serwera DoH, w polu „Dostosowany” / „Custom” wpisujesz pełny adres endpointu, np.:

• https://dns.nextdns.io/<Twój-ID>
• https://doh.mojadomena.pl/dns-query

W tle przeglądarka sprawdza, czy endpoint akceptuje zapytania DoH zgodne ze standardem RFC 8484. Jeśli coś jest skonfigurowane niezgodnie ze specyfikacją albo serwer ma problemy z certyfikatem TLS, Chrome zwykle po prostu wróci do klasycznego DNS (lub zgłosi błąd), zamiast czytelnie poinformować, że „DoH nie działa”. Czasem jedynym objawem jest brak wpisów w panelu twojego dostawcy DoH.

DNS over HTTPS w systemie Windows – konfiguracja na poziomie całego systemu

Wbudowany DoH w Windows 10 i 11

Microsoft dodał natywne wsparcie DoH najpierw do Windows 10 (od określonej aktualizacji), a potem rozszerzył je w Windows 11. Dzięki temu można ustawić szyfrowany DNS raz – w systemie – i korzystają z niego wszystkie aplikacje, które respektują ustawienia systemowe.

Konfiguracja graficzna w Windows 11 (w 10 jest podobnie, ale nieco inaczej rozmieszczone opcje):

1. Otwórz Ustawienia → Sieć i internet.
2. Wybierz rodzaj połączenia (np. Ethernet albo Wi-Fi).
3. Kliknij nazwę aktualnie używanego połączenia.

Konfiguracja DoH w Windows 11 krok po kroku

1. Otwórz Ustawienia → Sieć i internet.
2. W sekcji połączeń wybierz Ethernet lub Wi‑Fi, w zależności od tego, z czego korzystasz.
3. Kliknij nazwę aktywnego połączenia (np. nazwę sieci Wi‑Fi).
4. Przewiń do sekcji Ustawienia IP i kliknij Edytuj.
5. Wybierz tryb Ręcznie i włącz odpowiednią wersję protokołu:
   • IPv4 – jeśli korzystasz z typowego domowego internetu,
   • opcjonalnie także IPv6, jeśli twój operator go obsługuje.
6. W polach Preferowany serwer DNS i Alternatywny serwer DNS wpisz adresy IP wybranego dostawcy, np.:
   • Cloudflare: 1.1.1.1 i 1.0.0.1
   • Google: 8.8.8.8 i 8.8.4.4
   • NextDNS: dedykowane IP widoczne w panelu usługi.
7. Przy każdym z serwerów DNS rozwiń listę Typ szyfrowania i wybierz:
   • DNS over HTTPS (szablon: dostawca) – jeśli Windows go zna (np. Cloudflare, Google), lub
   • DNS over HTTPS (szablon: niestandardowy) – jeśli korzystasz z mniej popularnego lub własnego endpointu.
8. W przypadku szablonu niestandardowego wpisz pełny URL DoH, np.:
   • https://cloudflare-dns.com/dns-query
   • https://dns.nextdns.io/<Twój-ID>
9. Zapisz zmiany przyciskiem Zapisz, rozłącz i połącz ponownie z siecią (lub zrestartuj kartę sieciową), aby wszystko „zaskoczyło”.

Mit bywa taki, że „wystarczy sam adres IP dostawcy, a DoH zadziała magicznie”. Rzeczywistość: Windows potrzebuje zarówno poprawnego IP, jak i odpowiedniego szablonu/URL, inaczej przejdzie na zwykły, nieszyfrowany DNS lub w ogóle zgłosi błąd.

Konfiguracja DoH w Windows 10

W Windows 10 jest bardzo podobnie, ale część opcji pojawiła się dopiero w nowszych aktualizacjach. Jeśli ich nie widzisz, system może być zbyt stary albo polityka firmowa je ukrywa.

1. Otwórz Ustawienia → Sieć i internet → Stan.
2. Kliknij Właściwości przy aktywnym połączeniu.
3. Przejdź do dolnej części okna, znajdź sekcję Ustawienia IP i kliknij Edytuj.
4. Przełącz na tryb Ręcznie i ustaw adresy DNS tak jak w Windows 11 (IPv4/IPv6).
5. Opcje szyfrowania DNS w Windows 10 bywają ukryte głębiej lub niedostępne w starszych buildach. Jeśli nie widzisz wyboru typu szyfrowania, masz dwa wyjścia:
   • zaktualizować system do najnowszej wersji Windows 10,
   • skorzystać z narzędzi zewnętrznych (np. klienta DoH/DoT) uruchamianego jako usługa systemowa.

W środowiskach korporacyjnych często wchodzą w grę GPO, które nadpisują własne ustawienia. Jeśli po zmianach DNS w panelu wciąż widzisz stare adresy w ipconfig /all, prawdopodobnie wygrywa polityka domenowa.

Sprawdzanie, czy DoH w Windows naprawdę działa

Po konfiguracji dobrze jest sprawdzić, czy system faktycznie używa szyfrowanego DNS, a nie tylko wygląda, jakby używał.

• W przeglądarce:
  • wejdź na stronę testową dostawcy (np. https://1.1.1.1/help dla Cloudflare),
  • sprawdź pola „Using DNS over HTTPS (DoH)” oraz „Resolver”.
• Z wiersza polecenia:
  • uruchom cmd jako zwykły użytkownik,
  • wykonaj nslookup example.com lub Resolve-DnsName example.com w PowerShell.

Nslookup i Resolve‑DnsName nie pokażą „mam DoH”, ale wskażą, z jakiego serwera DNS korzysta system (adres IP resolvera). Jeśli widzisz IP twojego dostawcy DoH, a nie routera (192.168.x.x) czy serwera operatora, jesteś na dobrej drodze.

Powszechne nieporozumienie: „jak tylko włączę DoH w systemie, nikt już nie zobaczy, jakie domeny odwiedzam”. DoH ukrywa treść zapytań DNS przed podsłuchiwaniem w sieci lokalnej czy przez prosty sniffing u operatora, ale sam dostawca DNS wciąż wie, o jakie domeny pytasz. Zmienia się miejsce, w którym zostawia się ślad, a nie fakt istnienia śladu.

Priorytet: DoH w przeglądarce vs DoH w Windows

Jeśli włączysz DoH zarówno w systemie, jak i w przeglądarce, nie dochodzi do „podwójnego szyfrowania DNS”. Mechanizm pracuje kaskadowo.

• Przeglądarka z własnym DoH (Firefox, Chrome, Edge z włączonym „secure DNS”):
  • wysyła zapytania bezpośrednio do wybranego endpointu DoH, z pominięciem resolvera systemowego,
  • systemowe ustawienia DoH są wtedy dla niej tylko planem B (np. w razie awarii własnego endpointu, jeśli tak została skonfigurowana).
• Aplikacje bez własnego DoH:
  • korzystają z konfiguracji systemu, czyli z tego, co ustawisz w Windows (klasyczny DNS lub DoH),
  • nie „wiedzą”, czy DNS jest szyfrowany – po prostu pytają system i dostają odpowiedź.

Dobry, praktyczny układ: w systemie ustawiasz jednego zaufanego dostawcę DoH jako bazę, a w przeglądarce – jeśli potrzebujesz innych funkcji (np. agresywnego filtrowania) – stosujesz własny endpoint, np. NextDNS lub serwer firmowy.

Konfiguracja DoH per‑interfejs i per‑profil sieci

Windows pozwala na różne ustawienia DNS dla różnych połączeń (Ethernet, Wi‑Fi, VPN). W praktyce oznacza to, że DoH może działać tylko w niektórych sieciach, a w innych – celowo nie.

• Typowy scenariusz domowy:
  • na interfejsie domowego Wi‑Fi ustawiasz DoH z filtrowaniem treści dla dzieci,
  • na karcie Ethernet (np. dokującej) pozostawiasz klasyczny DNS routera z wewnętrznymi rekordami.
• Scenariusz mobilny:
  • na profilu „niezaufana sieć publiczna” wymuszasz DoH do zewnętrznego dostawcy,
  • w sieci firmowej zostawiasz DNS dostarczany przez DHCP, bo tam i tak ruch przechodzi przez wewnętrzne serwery filtrujące.

Jeśli zależy ci na spójności, przejrzyj ustawienia dla każdego używanego interfejsu osobno. Zdarza się, że DoH „działa w domu na kablu, ale nie na Wi‑Fi”, po prostu dlatego, że konfiguracja została zmieniona tylko na jednym z nich.

DoH a VPN, proxy i filtry rodzicielskie w Windows

DoH na poziomie systemu potrafi wejść w konflikt z innymi elementami konfiguracji sieciowej, zwłaszcza gdy każde z nich „chce być mądrzejsze od reszty”.

• VPN:
  • wiele klientów VPN ustawia własne serwery DNS w tunelu i wymusza, by całość ruchu DNS przechodziła przez nich,
  • jeśli włączysz DoH do zewnętrznego dostawcy, część ruchu może omijać DNS VPN, co psuje geolokalizację lub dostęp do zasobów firmowych,
  • niektóre VPN-y blokują ruch DoH wprost, aby uniknąć „DNS leak”.
• Proxy i filtry HTTP:
  • gdy organizacja filtruje ruch po domenach na poziomie proxy, szyfrowany DNS utrudnia im robotę,
  • efekt bywa taki, że DoH jest blokowany lub zastępowany własnym resolverem z logowaniem.
• Filtry rodzicielskie / kontrola rodzicielska:
  • wiele narzędzi opiera się na przechwytywaniu zwykłego ruchu DNS na porcie 53,
  • po włączeniu DoH filtr nagle „ślepnie”, co psuje założony model ochrony dzieci,
  • niektóre nowocześniejsze rozwiązania przewidują DoH i implementują własny szyfrowany resolver, który trzeba ustawić w systemie zamiast dowolnego publicznego.

Zdarza się więc, że w konkretnej konfiguracji bardziej sensowne jest centralne, firmowe DoH niż walka o „totalną prywatność” z publicznym resolverem, który i tak zostanie przycięty na firewallu.

Konfiguracja DoH w Windows za pomocą PowerShell

Graficzny interfejs nie zawsze odsłania wszystkie możliwości. W nowszych wersjach Windows można zarządzać DoH z poziomu PowerShell, co przydaje się zwłaszcza przy automatyzacji lub gdy chcesz mieć pełną kontrolę nad szablonami.

Przykładowa sekwencja (uruchom PowerShell jako administrator):

# Dodanie nowego serwera DNS z obsługą DoH
Add-DnsClientDohServerAddress `
    -ServerAddress 1.1.1.1 `
    -DohTemplate "https://cloudflare-dns.com/dns-query" `
    -AllowFallbackToUdp $false `
    -AutoUpgrade $true `
    -Validate $true

# Ustawienie go jako preferowanego dla interfejsu o nazwie "Wi-Fi"
Set-DnsClientServerAddress `
    -InterfaceAlias "Wi-Fi" `
    -ServerAddresses 1.1.1.1

Parametr -AllowFallbackToUdp $false mówi systemowi, żeby nie wracał do klasycznego DNS przez UDP, jeśli DoH zawiedzie. To podejście „wszystko albo nic” – przydatne na przykład na laptopie w nieufnej sieci, ale kłopotliwe, jeśli endpoint DoH czasem miewa przerwy.

Z kolei -AutoUpgrade $true sprawia, że jeśli znasz tylko zwykły serwer DNS, Windows spróbuje sam „podnieść” go do DoH, jeśli ma odpowiedni szablon. Nie działa to z każdym dostawcą – głównie z tymi, których Microsoft wbudował w system.

DoH a wewnętrzne domeny i split‑DNS w Windows

W sieciach firmowych i zaawansowanych domowych (np. z serwerem NAS, kontrolerem domeny, własnym serwerem DNS) często używa się tzw. split‑DNS: te same domeny mają inne znaczenie wewnątrz i na zewnątrz sieci. DoH potrafi pokrzyżować ten model.

• Jeśli ustawisz w Windows globalnego, publicznego dostawcę DoH:
  • zapytania o domeny firmowe mogą trafić poza firmę i dać „nie istnieje”,
  • usługi typu intranet.firma.local przestają się rozwiązywać, bo publiczny resolver nic o nich nie wie.
• Jeśli ustawisz doH na wewnętrznym resolverze:
  • dostajesz pełną funkcjonalność lokalnych rekordów i jednocześnie szyfrowanie na trasie,
  • ale trzeba mieć serwer DNS, który potrafi mówić DoH i jest poprawnie wystawiony w sieci.

Praktyczny kompromis w Windows bywa taki: na interfejsie firmowym zostawiasz DNS z DHCP (bez własnego DoH lub z firmowym DoH, jeśli istnieje), a na interfejsach domowych i mobilnych używasz publicznego dostawcy DoH. W połączeniach VPN warto dokładnie sprawdzić, jak klient ustawia DNS – tam często nie da się „wygrać” z polityką bez złamania zasad bezpieczeństwa.

Diagnostyka problemów z DoH w Windows

Jeżeli po włączeniu DoH coś zaczyna się dziać „dziwnie”, lepiej sięgnąć po kilka prostych narzędzi niż strzelać na ślepo.

• ipconfig:
  • ipconfig /all – sprawdza, jakie serwery DNS widzi system na każdym interfejsie,
  • jeśli widzisz inne adresy niż ustawione w panelu (np. router zamiast publicznego IP), DNS może być wymuszany przez DHCP lub klienta VPN.
• Resolve‑DnsName (PowerShell):
  • Resolve-DnsName example.com -Server 1.1.1.1 – pozwala wymusić zapytanie do konkretnego serwera,
  • wynik nie pokaże „to było DoH”, ale pozwala odróżnić problem z serwerem od problemu z systemem.

Najczęściej zadawane pytania (FAQ)

Czym dokładnie jest DNS over HTTPS i czym różni się od zwykłego DNS?

DNS over HTTPS (DoH) to sposób wysyłania zapytań DNS w zaszyfrowanym kanale HTTPS, zamiast w otwartym protokole na porcie 53. Technicznie to te same pytania typu „jaki jest adres IP dla example.com?”, ale opakowane w ruch HTTPS na porcie 443.

Przy klasycznym DNS treść zapytania jest widoczna jak na pocztówce – operator, administrator hotspotu czy atakujący w tej samej sieci mogą zobaczyć, jakie domeny odwiedzasz i w niektórych przypadkach podmienić odpowiedź. Przy DoH widzą jedynie zaszyfrowane połączenie z konkretnym serwerem DoH, bez listy domen, o które pytasz.

Czy DNS over HTTPS jest bezpieczniejszy i czy naprawdę chroni moją prywatność?

Tak, w porównaniu ze zwykłym DNS DoH zwiększa bezpieczeństwo i prywatność na poziomie zapytań DNS. Utrudnia podsłuch w lokalnej sieci, ogranicza możliwość prostego spoofingu DNS oraz omija część filtrów opartych wyłącznie na blokadzie DNS po stronie operatora lub hotspotu.

Mit: „Po włączeniu DoH jestem anonimowy w sieci”. Rzeczywistość: ukrywasz tylko treść zapytań DNS przed pośrednikami. Operator nadal widzi, z jakimi adresami IP się łączysz, serwisy internetowe kojarzą cię po cookies i logowaniu, a dostawca DoH staje się nowym punktem, który widzi twoje zapytania. To jeden klocek w większej układance, nie magiczna peleryna niewidka.

Kiedy opłaca się włączyć DNS over HTTPS, a kiedy lepiej go nie używać?

Najwięcej zyskujesz w publicznych sieciach Wi‑Fi (kawiarnie, hotele, lotniska), gdzie nie masz kontroli nad infrastrukturą. DoH utrudnia wstrzykiwanie reklam, stron phishingowych czy „stron powitalnych” poprzez manipulację odpowiedziami DNS. Typowy przykład: siadasz w hotelu, łączysz się z Wi‑Fi, a DoH w przeglądarce wysyła zapytania do zaufanego resolvera zamiast do DNS hotelu.

W sieci domowej DoH ma sens, gdy sam świadomie wybierasz dostawcę DNS/DoH i rozumiesz, że możesz ominąć filtry w routerze (np. kontroli rodzicielskiej). W sieci firmowej samodzielne włączanie DoH bywa wręcz niepożądane – może obchodzić firmowe zabezpieczenia i łamać polityki bezpieczeństwa. Tu konfigurację zawsze trzeba uzgadniać z działem IT.

Czy DNS over HTTPS przyspiesza działanie internetu?

Samo włączenie DoH nie jest „turbo przyspieszaczem” internetu. Czas ładowania stron zależy głównie od opóźnień sieci, jakości połączenia i wydajności serwerów, a nie od tego, czy zapytanie DNS idzie przez port 53 czy 443. Szyfrowanie dodaje minimalny narzut, ale na współczesnym sprzęcie jest on praktycznie niezauważalny.

To, co realnie może dać przyspieszenie, to wybór dobrego resolvera (nieważne, czy przez DoH, czy klasyczny DNS). Publiczni dostawcy z serwerami blisko użytkowników i z cache’owaniem zapytań często odpowiadają szybciej niż „zamulony” DNS ISP. Mit: „DoH = szybkość”; trafniejsze jest „dobry resolver (często DoH) = mniej lagów przy pierwszym wejściu na stronę”.

Czy DNS over HTTPS omija blokady stron, cenzurę i kontrolę rodzicielską?

Bardzo często tak, bo wiele blokad opiera się wyłącznie na filtrowaniu DNS po stronie operatora, routera lub oprogramowania kontroli rodzicielskiej. Jeśli przeglądarka wysyła zapytania bezpośrednio do zewnętrznego dostawcy DoH, lokalne filtry DNS są po prostu pomijane.

To zaleta przy obchodzeniu nachalnej cenzury czy „twardych” blokad ISP, ale jednocześnie problem w domach, gdzie DNS w routerze służy do ochrony dzieci przed treściami dla dorosłych lub malware. Włączenie DoH w przeglądarce dziecka zwykle wyłącza ten mechanizm. Z technicznego punktu widzenia to nie „magiczne obejście”, tylko zmiana miejsca, w którym rozwiązywane są nazwy domen.

Komu ufam po włączeniu DNS over HTTPS i jak wybrać dostawcę DoH?

Przy klasycznym DNS głównym zaufanym punktem jest operator (lub właściciel routera, jeśli tam ustawiono własny DNS). Po przejściu na DoH przenosisz zaufanie na dostawcę usługi DoH – to on widzi twoje zapytania DNS, może je analizować, filtrować i logować.

Kluczowe kryteria wyboru to: jasna polityka prywatności (jak długo trzymane są logi, czy są powiązane z IP użytkownika), wsparcie dla DNSSEC, ewentualne filtry antyphishingowe oraz reputacja operatora. Mit: „dostawca bez logów nic nie wie” – w praktyce prawie każdy potrzebuje chociaż minimalnych logów operacyjnych; liczy się to, czy da się z nich odtworzyć historię konkretnego użytkownika.

Najważniejsze punkty

• DNS over HTTPS szyfruje jedynie zapytania DNS, „opakowując” je w ruch HTTPS na porcie 443, więc dla operatora czy hotspotu wyglądają jak zwykłe połączenie z jednym serwerem, a treść zapytania (konkretna domena) przestaje być czytelna.
• Klasyczny DNS jest w pełni jawny – każdy pośrednik w sieci (router, operator, administrator Wi‑Fi) może podglądać, jakie domeny odwiedzasz, logować ten ruch, blokować strony lub podmieniać odpowiedzi (np. na reklamy czy phishing).
• DoH znacząco utrudnia podsłuch i manipulację DNS w publicznych sieciach Wi‑Fi, bo zamiast serwera wskazanego przez hotel czy kawiarnię korzystasz z własnego, zaufanego dostawcy; typowy atak z fałszywym hotspotem staje się wtedy dużo trudniejszy.
• Mit: „Po włączeniu DoH jestem niewidzialny”. Rzeczywistość: operator nadal widzi adresy IP, z którymi się łączysz, serwisy nadal śledzą cię przez cookies i logowanie, a DoH to tylko jeden klocek obok VPN, ustawień przeglądarki i zdrowych nawyków.
• Dostawca DoH staje się nowym zaufanym punktem – widzi twoje zapytania DNS, a choć zwykle ogranicza logi lub je anonimizuje, to całkowity brak danych technicznych jest mitem; kluczowy jest wybór operatora i jego polityki prywatności.
• W sieci domowej DoH może poprawić prywatność względem ISP, ale jednocześnie potrafi obejść lokalne filtry DNS (np. kontrolę rodzicielską w routerze), co prowadzi do chaosu, gdy część urządzeń jest filtrowana, a część omija te zabezpieczenia.