DNS over HTTPS, DNS over TLS i VPN: kto naprawdę widzi, co robisz w sieci

Co tak naprawdę widać w sieci: podstawy zamiast mitów

Metadane kontra treść – co mówi więcej o użytkowniku

Większość użytkowników myśli o prywatności w kategoriach „kto może przeczytać to, co wpisuję” – hasła, wiadomości, formularze. Tymczasem dla analityka sieci dużo cenniejsze są metadane: kiedy się łączysz, z kim, jak często, jak długo, z jakiego urządzenia. W wystarczająco długiej perspektywie taka mapa aktywności mówi o człowieku więcej niż pojedyncza treść wiadomości.

Treść to na przykład zawartość strony internetowej, tekst maila, plik, który pobierasz. Metadane to adresy IP, do których się łączysz, nazwy domen z zapytań DNS, godzina połączenia, jego długość, ilość przesłanych danych, a nawet schemat „bursty” w ruchu (charakterystyczny np. dla wideo, gier, VoIP). Dzięki temu można odgadnąć, czy oglądasz streaming, grasz online, synchronizujesz backup, czy tylko czytasz teksty.

Szyfrowanie HTTPS czy VPN w większości przypadków ukrywa treść, ale nie usuwa metadanych. Część z nich nadal jest dostępna na którymś etapie trasy pakietu. Dlatego odpowiedź na pytanie „kto naprawdę widzi, co robisz w sieci” sprowadza się do tego, kto ma dostęp do jakiego zestawu metadanych oraz na ile potrafi je zinterpretować.

Jeśli ktoś widzi tylko zaszyfrowany strumień danych bez kontekstu (np. ISP przy dobrym VPN), to może odczytać z niego rytm dnia, objętość ruchu, ale już niekoniecznie konkretne serwisy czy treści. Jeśli ktoś widzi pełne logi DNS (np. dostawca DNS over HTTPS lub DNS over TLS), ma za to niemal kompletną listę serwisów, z którymi się komunikujesz, nawet jeśli połączenie właściwe realizuje się szyfrowanym HTTPS.

Warstwy komunikacji: od DNS po TLS i VPN

Komunikacja w sieci to kilka warstw, przez które przechodzi każdy pakiet, zanim dotrze do celu. Każda z tych warstw może być logowana, filtrowana lub analizowana przez inne podmioty. W uproszczeniu:

• DNS – tłumaczy nazwy (np. bank.pl) na adresy IP.
• IP/transport (TCP/UDP) – przenosi pakiety między adresami IP po określonych portach.
• TLS/HTTPS – szyfruje treść (np. zawartość strony, logowanie) i część informacji o tym, do jakiej usługi się łączysz.
• VPN – tworzy dodatkowy szyfrowany tunel, który owija cały powyższy ruch między twoim urządzeniem a serwerem VPN.

Każda warstwa ma swoje „okienko”, przez które coś widać. DNS pokazuje, jakie domeny odwiedzasz. Warstwa IP ujawnia adresy IP nadawcy i odbiorcy oraz porty (np. 443 dla HTTPS). TLS często ukrywa treść, ale częściowo może zdradzać nazwę domeny (SNI, a w nowszych wersjach ECH ją ukrywa). VPN z kolei przenosi ten cały pakiet w kapsule, którą widzi tylko ISP i serwer VPN.

Samo użycie DNS over HTTPS czy DNS over TLS przesuwa widoczność z poziomu twojego operatora internetowego na poziom zewnętrznego dostawcy DNS. VPN przesuwa zaufanie z ISP na operatora VPN. Pytanie nie brzmi więc „jak ukryć wszystko przed wszystkimi”, tylko komu chcesz ufać i przed kim chcesz się ukryć.

Przykład z życia: użytkownik w kawiarni i serwisy społecznościowe

Wyobraźmy sobie osobę korzystającą z publicznego Wi‑Fi w kawiarni. Wchodzi na popularny portal społecznościowy, kilka serwisów informacyjnych, może bank. Co widać po drodze?

• Operator Wi‑Fi / administrator sieci w kawiarni – przy klasycznym DNS widzi nazwy domen z zapytań DNS oraz adresy IP serwerów, z którymi się łączysz. Jeśli ruch jest w HTTPS, nie widzi treści, ale nazwy domen i tak zdradzają, gdzie zaglądasz. Bez HTTPS widziałby także pełną treść.
• ISP kawiarni – widzi to samo co administrator sieci, z tym że na poziomie całej kawiarni, a nie pojedynczego urządzenia. Jeśli ty używasz VPN, a inni nie – w jego logach wyróżniasz się zaszyfrowanym tunelem do serwera VPN.
• Dostawca twojego DNS (domyślnie często ISP) – widzi wszystkie domeny, o które pytasz w zapytaniach DNS. Przy DNS over HTTPS lub DNS over TLS to może być Cloudflare, Google albo inny dostawca – wtedy pełna mapa twoich domen trafia właśnie do nich.
• Dostawca VPN (jeśli go używasz) – widzi docelowe IP, wolumen ruchu, wzorce połączeń, a po stronie swoich serwerów też logi DNS, jeśli korzystasz z ich resolvera.
• Właściciel serwisu (np. portalu społecznościowego) – widzi twoje działania w swoim serwisie: logi, kliknięcia, dane profilowe, adres IP widoczny po stronie serwisu (przy VPN będzie to IP serwera VPN, a nie twoje).

Zmiana ustawień na DNS over HTTPS, DNS over TLS czy dodanie VPN głównie przesuwa punkt koncentracji wiedzy o twojej aktywności z jednego pośrednika na innego – nie likwiduje śladów. Cała sztuka polega na takim skomponowaniu tych technologii, by ograniczyć dostęp do danych tym podmiotom, przed którymi rzeczywiście chcesz się chronić.

Klasyczny DNS: gdzie wyciekają informacje o tym, co robisz

Jak działa tradycyjny DNS w praktyce

Klasyczny DNS jest prosty: gdy wpisujesz w przeglądarce example.com, system wysyła zapytanie do serwera DNS skonfigurowanego na twoim urządzeniu lub routerze (najczęściej to serwer ISP). Zapytanie leci protokołem UDP (czasem TCP) na port 53, w postaci niezaszyfrowanej. Każdy po drodze, kto ma wgląd w ruch sieciowy (administrator sieci, ISP, czasem operator Wi‑Fi), może je odczytać i zapisać.

Zapytanie DNS zawiera nazwę domeny i typ rekordu (najczęściej A lub AAAA – adres IPv4/IPv6). Serwer DNS odsyła odpowiedź z adresem IP. Ten cały proces jest bardzo szybki i zazwyczaj powtarza się przy każdym nowym serwisie, z którego korzystasz, a także przy różnych poddomenach (np. api.bank.pl, grafika.bank.pl itd.).

W klasycznym scenariuszu każde zapytanie jest czytelne dla wszystkich pośredników między twoim urządzeniem a serwerem DNS. Nie ma znaczenia, czy późniejsze połączenie z tą domeną używa HTTPS. Sama nazwa domeny już mówi bardzo dużo: odsłania rodzaj usługi, często konkretną firmę, tematykę strony, a nierzadko także wrażliwe kategorie (zdrowie, finanse, przekonania).

Stąd tak duże zainteresowanie operatorów ruchem DNS – jest lekki, prosty do logowania, a jednocześnie niezwykle informacyjny. To właśnie na tym poziomie działają blokady stron, filtry rodzicielskie czy firmowe systemy DLP (data loss prevention), które mają „pilnować”, gdzie pracownicy zaglądają.

Dlaczego same nazwy domen tak dużo zdradzają

Nazwy domen są często dużo bardziej wymowne niż sama treść sesji HTTPS. Przykłady mówią najwięcej:

• Odwiedziny domeny w rodzaju onkologia‑miasto.pl, klinika‑nieplodnosci.pl – mówią coś o stanie zdrowia czy sytuacji życiowej, nawet bez znajomości treści.
• Logowanie na moja‑bankowosc.pl lub bankXYZ.pl – potwierdza, w jakim banku masz konto.
• Wejścia na portal‑randkowy.pl, serwis‑dla‑doroslych.com – zdradzają preferencje, zwyczaje, a czasem orientację czy status relacji.
• Regularne połączenia z domenami konkretnej konkurencyjnej firmy przy firmowym łączu – mogą wskazywać na rozmowy rekrutacyjne, analizę konkurencji, a nawet wyciek informacji.

To tylko domeny główne. W praktyce ruch generuje też wiele poddomen o nazwach wskazujących na funkcję techniczną czy produktową („crm”, „support”, „panel‑klienta”, „vpn”, „beta”). W połączeniu z timestampami i częstotliwością zapytań powstaje pełen obraz nawyków użytkownika, firmy czy nawet całego gospodarstwa domowego.

Dlatego „tylko DNS” wcale nie jest mało ważny. W wielu przypadkach to właśnie logi DNS pozwalają zrekonstruować historię aktywności z dokładnością do serwisu, a czasem do funkcji w serwisie, mimo że wszystko inne było szyfrowane.

Kto zbiera dane DNS i co z nimi robi

Domyślnie serwerem DNS jest najczęściej twój dostawca internetu (ISP). To oznacza, że ma on pełny wgląd w historię zapytań DNS z twojego łącza lub karty SIM. Taka historia może być:

• logowana do celów technicznych (diagnostyka, bezpieczeństwo sieci);
• analizowana statystycznie (raporty popularności domen);
• wykorzystywana marketingowo (profilowanie klientów, sprzedaż zbiorczych danych);
• udostępniana służbom na wniosek, zgodnie z lokalnym prawem;
• wykorzystywana do blokad i cenzury (blokowanie konkretnych domen).

Drugim podmiotem jest administrator sieci lokalnej – firmowe IT, właściciel routera w hotelu, operator sieci szkolnej. W wielu konfiguracjach to ich serwer DNS jest wykorzystywany w pierwszej kolejności, zwłaszcza jeśli w sieci działa podsłuch lub wymuszony DNS (przez przekierowanie ruchu na port 53 do własnego resolvera). Wtedy to oni widzą pełną listę domen używanych w sieci.

Jeśli ręcznie ustawisz DNS na publiczny (np. Google Public DNS, Cloudflare), historia trafia do tych firm. Zyskujesz częściowe odcięcie od oczu lokalnego ISP, ale przekazujesz dane innemu scentralizowanemu graczowi. Cloudflare i Google deklarują różne poziomy anonimizacji czy retencji danych, jednak technicznie możliwość profilowania pozostaje.

Filtracja, cenzura i inne zastosowania DNS

Poziom DNS jest wygodnym miejscem do nakładania filtrów, bo:

• jest centralny – wszystkie urządzenia pytają o domeny w jedno miejsce, jeśli nie kombinujesz z konfiguracją;
• nie wymaga analizy treści – wystarczy porównać nazwę domeny z listą zabronionych lub dozwolonych;
• jest stosunkowo tani obliczeniowo.

Dlatego wielu ISP i administratorów sieci wykorzystuje DNS do:

• blokowania treści nielegalnych (np. na podstawie lokalnego prawa);
• implementacji filtrów rodzicielskich (blokady domen „+18”, hazardowych, itp.);
• blokowania reklam i trackerów (w konfiguracjach prywatnych, np. Pi‑hole);
• wymuszania użycia własnych usług (np. przekierowanie na stronę informacyjną).

Z technicznego punktu widzenia blokada wygląda zwykle jak odpowiedź DNS z innym adresem IP (np. strona z komunikatem) lub informacja, że domena nie istnieje. Użytkownik często widzi tylko błąd lub komunikat „strona zablokowana”. Cała akcja odbywa się zanim dojdzie do jakiegokolwiek połączenia HTTP czy HTTPS z oryginalnym serwerem.

Ograniczenia klasycznego DNS: czego nie da się odczytać

Mimo tego DNS ma też ograniczenia. Dostawca DNS nie widzi:

• co dokładnie robisz na stronie po wejściu – nie zna konkretnych URL‑i, treści, formularzy, plików;
• czy się logujesz, z jakiego konta, jakie dane wpisujesz;
• co przesyłasz w ruchu aplikacji, np. w komunikatorze używającym jednego stałego endpointu.

W praktyce oznacza to: DNS daje mapę, gdzie bywasz, ale nie pokazuje krok po kroku, co robisz w środku. Jednak przy współczesnym internecie i tak często wystarcza to do klasyfikacji zainteresowań, zawodu, stanu zdrowia, sytuacji finansowej czy preferencji politycznych. Dlatego tak istotne są technologie szyfrujące zapytania DNS – DNS over HTTPS i DNS over TLS – ale pod warunkiem, że rozumiesz ich realne skutki.

DNS over HTTPS (DoH) – szyfrowanie DNS w przeglądarce i systemie

Jak działa DNS over HTTPS technicznie, ale po ludzku

DNS over HTTPS (DoH) bierze klasyczne zapytanie DNS i pakuje je do normalnego zapytania HTTPS. Zamiast wysyłać otwarte UDP na port 53 do serwera DNS, przeglądarka lub system wysyłają żądanie HTTPS na określony adres (np. https://dns.cloudflare.com/dns‑query) na porcie 443.

Dla sieci z zewnątrz ten ruch wygląda jak zwykły ruch do jakiejś strony WWW. Treść zapytania DNS (domena, typ rekordu) jest zaszyfrowana warstwą TLS. Operator Wi‑Fi, administrator firmowy czy ISP widzą, że twoje urządzenie utrzymuje połączenie HTTPS z serwerem DoH danego dostawcy, ale nie widzą, o jakie domeny pytasz.

Na końcu tej komunikacji stoi dostawca DoH – najczęściej duży operator DNS, taki jak Cloudflare, Google, Quad9 czy NextDNS. To on odszyfrowuje zapytania DNS i wysyła standardowe zapytania w świat lub korzysta z własnego cache’a. Innymi słowy, DoH przesuwa widoczność z twojego ISP na dostawcę DoH, a po drodze ukrywa zapytania przed lokalną siecią.

Co dokładnie ukrywa DoH, a co nadal widać

DoH rozwiązuje konkretny problem: podsłuch i manipulację zapytań DNS po drodze między twoim urządzeniem a resolverem. To dużo, ale nie cudowna peleryna niewidka. Z perspektywy obserwatora sytuacja wygląda tak:

• Administrator sieci lokalnej / właściciel Wi‑Fi:
  • nie widzi już listy domen, o które pytasz przez DNS;
  • widzi, że nawiązujesz połączenia TLS (HTTPS) do konkretnych IP i domen (przez SNI/ESNI/QUIC – o tym za chwilę);
  • widzi, że twoje urządzenie gada np. z dns.google czy cloudflare-dns.com.
• Twój ISP:
  • ma bardzo podobny widok do administratora sieci lokalnej;
  • nie widzi nazw domen w zapytaniach DNS, jeśli wszystkie aplikacje używają DoH;
  • widzi, że łączysz się z konkretnymi adresami IP, z których sporą część można powiązać z domenami.
• Dostawca DoH:
  • widzi wszystkie nazwy domen, o które pytasz jego serwer;
  • nie widzi twojej pełnej historii ruchu HTTP/HTTPS (treści, URL‑i, ciasteczek);
  • w wielu przypadkach zna twój adres IP albo możliwość jego powiązania z kontem (np. logujesz się do panelu).

DoH zmienia więc rozkład zaufania. Zmniejsza możliwości lokalnych pośredników i państwowego operatora, ale wzmacnia rolę globalnych dostawców DNS. Popularna rada „włącz DoH i jesteś prywatny” ma sens, jeśli głównym problemem jest ciekawski administrator szkoły, korporacji czy dostawca internetu, lecz mniej, jeśli obawiasz się centralizacji danych u jednego z kilku globalnych graczy.

Autonomiczny DoH w przeglądarce vs DoH na poziomie systemu

Praktyczny kłopot z DoH polega na tym, że można go wdrożyć na dwóch poziomach, a ludzie często myślą, że „wystarczy raz gdzieś kliknąć”.

• DoH w przeglądarce (Firefox, Chrome, Edge):
  • szyfruje zapytania DNS używane tylko przez tę przeglądarkę;
  • nie obejmuje innych aplikacji: komunikatorów, gier, klienta poczty, systemowych aktualizacji;
  • często korzysta z wbudowanej listy dostawców (domyślnie np. Cloudflare), co upraszcza konfigurację, ale przenosi dane do konkretnych firm.
• DoH na poziomie systemu (Windows 11, Android, niektóre dystrybucje Linuksa):
  • systemowy resolver DNS wysyła zapytania DoH do skonfigurowanego serwera;
  • wszystkie aplikacje używające systemowego DNS „dziedziczą” szyfrowanie;
  • wymaga ręcznej konfiguracji lub profilu (MDM w firmie);
  • wciąż dopuszcza, że aplikacja sama wdroży własny DNS (np. aplikacja VPN, tor‑browser, niektóre przeglądarki).

Odpowiedź na pytanie „czy ktoś widzi moje DNS” zależy więc od tego, które aplikacje faktycznie używają DoH, a które omijają system. Typowy scenariusz: przeglądarka ma własny DoH do Cloudflare, systemowy DNS leci do operatora komórkowego, a aplikacja VPN modyfikuje oba. Bez świadomego porządku kończy się to trudnym do przewidzenia miksem polityk prywatności i jurysdykcji.

Popularne mity wokół DoH

Kilka obiegowych opinii dobrze wygląda w prezentacjach, ale gorzej w zderzeniu z praktyką:

• „DoH ukrywa, jakie strony odwiedzam” – nie do końca. Ukrywa listę domen w warstwie DNS przed lokalnym operatorem, ale:
  • wielu operatorów potrafi powiązać adresy IP z domenami i usługami (na podstawie własnych baz czy pasywnego fingerprintingu);
  • certyfikat TLS i pole SNI (o ile nie jest szyfrowane – ESNI/ECH) też zdradzają domenę przy nawiązywaniu połączenia.
• „Jak włączę DoH, ominę wszystkie blokady” – tylko tam, gdzie faktycznie blokuje się po DNS. Gdy w grę wchodzi blokada IP, filtrowanie SNI czy DPI, DoH nic nie zmienia.
• „DoH jest zawsze lepsze niż klasyczny DNS” – bywa wolniejsze (więcej narzutu na TLS, choć w praktyce cache i HTTP/2 to amortyzują), bywa też problematyczne w sieciach firmowych, gdzie DNS jest elementem bezpieczeństwa (np. wykrywanie malware, split‑DNS do zasobów wewnętrznych). Tam bezmyślne włączenie DoH często psuje rzeczy, które wcześniej działały.

Scenariusze, w których DoH jest szczególnie sensowny

DoH błyszczy przede wszystkim tam, gdzie kontrolujesz końcówkę, ale nie kontrolujesz sieci pośredniej:

• podróżujesz i logujesz się do przypadkowych Wi‑Fi (hotele, kawiarnie, pociągi);
• korzystasz z sieci w akademiku lub w pracy, gdzie nie chcesz, aby lokalne IT miało pełny wgląd w twoje DNS (prywatne zakładki, logowanie do kont osobistych);
• masz ograniczone zaufanie do ISP, ale jesteś gotów obdarzyć nim konkretnego dostawcę DNS, którego politykę prywatności dokładnie przeczytałeś.

Dużo gorzej sprawdza się w sieciach, gdzie DNS jest częścią świadomie zbudowanej polityki bezpieczeństwa (firmy, administracja, laboratoria), a użytkownik próbuje „na skróty” ominąć mechanizmy ochrony, które faktycznie mają sens (np. blokady znanych domen C&C, phishingu, wycieków danych). Tam rozsądniejsze jest wdrożenie szyfrowanego DNS na poziomie infrastruktury, zamiast ucieczka w losowy publiczny resolver.

DNS over TLS (DoT) – szyfrowany DNS poza HTTP

Różnica między DoH a DoT bez marketingowej mgły

DNS over TLS (DoT) rozwiązuje ten sam problem co DoH: szyfruje zapytania DNS między tobą a resolverem. Robi to jednak w sposób bardziej „networkowy” niż „webowy”.

• Transport:
  • DoH używa HTTP(S) na porcie 443 – wygląda jak zwykły ruch WWW;
  • DoT używa czystego TLS nad DNS, zazwyczaj na porcie 853 – sitka filtrujące mogą łatwiej go rozpoznać jako „ruch DNS”.
• Integracja:
  • DoH chętnie adoptują przeglądarki i aplikacje;
  • DoT naturalnie przyjmuje się w routerach, systemowych resolverach i infrastrukturze operatorów.

Z perspektywy prywatności różnica jest subtelna: w obu przypadkach dostawca szyfrowanego DNS widzi całość twojej historii DNS. Z perspektywy admina sieci – kluczowa. DoT da się względnie łatwo dopuścić, kontrolować lub blokować jako wyraźnie oznaczony kanał DNS, podczas gdy DoH stapia się z ruchem HTTPS.

DoT na routerze i w systemie: inny model zaufania

Najczęściej DoT pojawia się w dwóch miejscach.

• Router domowy lub firmowy:
  • router pyta „świat” o DNS po DoT (np. do Quad9, Cloudflare, operatora),
  • urządzenia w sieci nadal mówią z routerem po „zwykłym” DNS (UDP/53),
  • dostawca internetu nie widzi już, o jakie domeny pyta twoja sieć – widzi tylko szyfrowany strumień TLS do jednego lub kilku resolverów;
  • administrator routera nadal widzi wszystko, bo to on jest lokalnym resolverem.
• Systemowy resolver na urządzeniu:
  • Windows, Android czy Linux mogą same mówić DoT do wybranego serwera;
  • cały DNS z urządzenia jest wtedy szyfrowany „od źródła”, z pominięciem routera (który tylko przekazuje TLS dalej);
  • router przestaje być miejscem analizy DNS – wszystko skupia się u dostawcy DoT.

O ile DoH bywa „indywidualnym buntem” pojedynczej przeglądarki, o tyle DoT łatwiej wprowadzić na poziomie infrastruktury domowej lub firmowej: jeden router, a korzysta cała sieć. W zamian tracisz część granularnej kontroli – pojedyncze aplikacje rzadziej obsługują DoT na własną rękę.

Kiedy DoT ma przewagę nad DoH

Technicznie DoT jest prostszy dla wielu elementów sieci. Kilka sytuacji, gdzie zazwyczaj sprawdza się lepiej niż DoH:

• chcesz mieć centralne logowanie lub filtrowanie DNS (np. Pi‑hole, AdGuard Home) i jednocześnie szyfrowanie między routerem a światem;
• zarządzasz małą firmową siecią i zależy ci, by użytkownicy nie uciekali na „prywatne” DoH, obchodząc analitykę bezpieczeństwa – łatwiej konsekwentnie wdrożyć DoT w routerach i endpointach;
• masz urządzenia IoT, które nie znają pojęcia DoH, ale chcesz, by ich DNS poza domem i tak był szyfrowany – router z DoT załatwia sprawę bez aktualizacji lodówki.

Nieco przewrotna rada: jeśli celem jest kontrolowana, a nie absolutnie indywidualna prywatność (np. w rodzinie, w firmie, w małej organizacji), DoT na infrastrukturze bywa bezpieczniejszym kompromisem niż sytuacja, w której każdy użytkownik konfiguruje własne DoH „jak mu się kliknie”.

Gdzie DoT zawodzi oczekiwania

DoT nie ukryje twoich DNS tam, gdzie przeszkodą jest nie podsłuch, tylko regulacyjny lub techniczny przymus:

• nie ominie blokad, jeśli państwowy regulator wymusza blokowanie na poziomie IP lub na poziomie samego resolvera, z którego musisz korzystać (np. operator mobilny blokuje zewnętrzne porty);
• nie chroni przed administratorem routera – jeśli np. korzystasz z cudzej sieci, właściciel może widzieć twoje zapytania, gdy router jest lokalnym resolverem, a dopiero on mówi DoT na zewnątrz;
• nie rozwiązuje problemu centralizacji – wciąż musisz wybrać, komu ufasz jako operatorowi DNS (ISP, globalny dostawca, własny serwer na VPS‑ie).

VPN – tunel szyfrujący wszystko… ale nie przed każdym

Co VPN faktycznie robi z twoim ruchem

VPN to warstwa niżej niż DoH/DoT. Zamiast szyfrować tylko DNS, owija cały ruch sieciowy w tunel między twoim urządzeniem (lub routerem) a serwerem VPN. Dla lokalnego operatora wygląda to jak ciąg zaszyfrowanych pakietów do jednego IP: serwera VPN.

W praktyce dzieje się kilka rzeczy naraz:

• twoje pakiety (DNS, HTTP, TLS, cokolwiek) lecą szyfrowanym tunelem do serwera VPN;
• serwer VPN „odpakowuje” je i wysyła dalej w świat tak, jakby to on był twoim urządzeniem;
• serwisy, z którymi się łączysz, widzą adres IP serwera VPN, a nie twój domowy czy mobilny;
• większość konfiguracji VPN przekierowuje również DNS przez tunel, tak że zapytania DNS wychodzą z serwera VPN, a nie z twojej lokalnej sieci.

Efekt: lokalny ISP, administrator Wi‑Fi i państwowy operator twojej karty SIM tracą wgląd w szczegóły ruchu (o ile VPN jest poprawnie skonfigurowany). Zyskuje go za to operator VPN, bo to on staje się nowym „punktem widzenia” całego twojego internetu.

VPN a DNS: kto jest twoim nowym „dostawcą prawdy”

Wiele poradników chwali VPN jako sposób na ukrycie DNS. To tylko połowa historii. Typowy scenariusz:

• łączysz się z serwerem VPN;
• konfiguracja VPN nadpisuje DNS na adresy należące do operatora VPN lub do wybranego przez niego dostawcy (np. Cloudflare, Google, własny resolver z filtracją);
• wszystkie twoje aplikacje pytają teraz o domeny przez tunel – lokalny ISP ich nie widzi;
• za to operator VPN widzi zarówno twoje DNS, jak i docelowe adresy IP, czasy połączeń i wielkości transferów.

Niektóre VPN‑y reklamują się jako „bez logów”. To kierunek, ale pojęcie no‑logs bywa luźno interpretowane. Technicznie serwer VPN musi przetwarzać twoje żądania, a więc ma możliwość ich logowania, profilowania czy kojarzenia z płatnością lub mailem. Pytanie brzmi, na ile:

• polityka prywatności ogranicza to prawnie;
• architektura i jurysdykcja ograniczają to praktycznie (brak dysków, audyty, brak obowiązku retencji, brak ingerencji właściciela DC).

Gdzie VPN realnie ogranicza ciekawskich, a gdzie tylko przesuwa problem

Najuczciwiej traktować VPN nie jako „płaszcz niewidkę”, tylko narzędzie do zmiany punktu obserwacji. Zmienia to, kto widzi najwięcej, ale nie likwiduje obserwatora.

Przykłady sytuacji, w których VPN zwykle robi dużą różnicę:

• publiczne i półpubliczne Wi‑Fi – hotele, kawiarnie, uczelniane hotspoty; lokalny admin i inni użytkownicy sieci przestają widzieć twoje sesje HTTP/HTTPS i DNS, o ile cały ruch faktycznie przechodzi przez tunel;
• operatorzy mobilni i domowi ISP – tracą wgląd w konkretne domeny i adresy IP docelowe, o ile:
  • VPN wymusza własne DNS (brak „DNS leak”);
  • nie korzystasz równolegle z aplikacji, które wychodzą poza tunel (split tunneling, „zaufane” sieci).

Jest też druga strona medalu – przypadki, gdzie VPN głównie przesuwa problem zaufania:

• przed dużymi platformami (Google, Meta, Microsoft) VPN zmienia niewiele – nadal logujesz się na konto, dostarczasz im pełny kontekst swoich działań; dochodzi tylko dodatkowy adres IP pośrednika;
• przed zaawansowaną analityką ruchu (np. państwową na stykach sieci) sam VPN bywa za słaby – szyfrowanie utrudnia podgląd treści, ale korelacja czasowa i analiza wzorców ruchu nadal mogą dużo zdradzić;
• w pracy lub szkole, gdzie IT ma kontrolę nad systemem lub wymusza własny VPN korporacyjny, prywatny VPN na wierzchu rzadko da pełną anonimowość – administrator i tak zarządza końcówką.

Popularna rada „odpal VPN i jesteś anonimowy” rozbija się o proste pytanie: czy zmieniłeś tylko adres IP, czy też zmienił się model zaufania i ekspozycji danych?

Typowe mity o anonimowości VPN

Wokół VPN narosło kilka powtarzalnych mitów. Z punktu widzenia prywatności i DNS ważne są głównie trzy.

1. „VPN ukryje wszystko przede wszystkimi”
   Nie ukryje:
   • przed operatorem VPN – widzi on twój ruch po „drugiej stronie tunelu” (adresy IP, DNS, metadane);
   • przed serwisami, w których się logujesz – konto użytkownika jest jednoznaczniejsze niż IP;
   • przed malware na twoim urządzeniu – zainfekowana końcówka wysyła dane zaszyfrowanym tunelem tak samo chętnie.
2. „VPN = brak logów = pełne bezpieczeństwo”
   Hasło no‑logs zmieniło się w marketing. Różnica między:
   • „nie logujemy na stałe” – ale chwilowo buforujemy dane do debugowania, korelacji sesji, ochrony przed nadużyciami;
   • „nie logujemy, bo nie mamy gdzie ani jak” – brak dysków, ograniczona telemetria, zewnętrzne audyty, żaden panel dla supportu, który „na żądanie” podejrzy sesję.

   Tylko ten drugi wariant faktycznie zmniejsza ilość danych, które można wykorzystać przeciwko tobie.

3. „VPN rozwiąże problem państwowej cenzury / retencji”
   VPN może:
   • obejść proste blokady DNS lub IP na poziomie lokalnego ISP;
   • utrudnić dopasowanie twojego ruchu do lokalnej karty SIM lub łącza kablowego.

   Nie poradzi sobie z:

   • obowiązkiem retencji po stronie VPN w krajach z agresywnym prawem nadzoru;
   • blokadą samych serwerów VPN i detekcją protokołów (DPI, sygnatury ruchu);
   • faktem, że część serwisów wymaga danych osobowych (bankowość, usługi publiczne) – ruch przez VPN nie usuwa śladu w tych systemach.

Kiedy VPN, a kiedy wystarczy DoH/DoT

W praktyce dużo osób używa VPN tam, gdzie wystarczyłoby dobranie sensownego szyfrowanego DNS, i odwrotnie. Rozróżnienie można uprościć do pytania: co dokładnie chcesz ukryć i przed kim?

Scenariusze, gdzie DoH/DoT zazwyczaj wystarczy:

• chodzi głównie o to, by ISP nie budował pełnego profilu z twoich DNS, a nie o ukrycie IP przed odwiedzanymi serwisami;
• korzystasz głównie z HTTPS, nie dotykasz wiele usług w czystym HTTP czy innych nieszyfrowanych protokołów;
• działa w twoim przypadku model: „ufam konkretnemu dostawcy DNS bardziej niż anonimowemu dostawcy VPN z agresywnym marketingiem”.

Scenariusze, gdzie VPN faktycznie ma przewagę:

• musisz ukryć adres IP przed serwisami docelowymi (np. geoblokady, chcesz rozdzielić tożsamości, testy z różnych regionów);
• używasz aplikacji poza HTTP(S) (gry, P2P, protokoły legacy), gdzie same DNS‑y nie mówią wszystkiego, a ruch nadal może być podsłuchany;
• istotne jest, aby lokalny admin nie widział nawet metadanych typu „łączysz się teraz z SIP, SSH, IMAP”, tylko jedną sesję do VPN.

Strategia „zawsze VPN, zawsze DoH” ma sens głównie u osób, które w pełni świadomie akceptują nowy model zaufania: duża koncentracja danych u jednego operatora (VPN lub szyfrowany DNS), dokładnie wybranego i zweryfikowanego.

Łączenie VPN z DoH/DoT: kiedy to ma sens, a kiedy psuje obraz

Można, a czasem wręcz trzeba łączyć szyfrowany DNS z VPN. Problem w tym, że łatwo stworzyć sobie układ, który wygląda „hardkorowo prywatnościowo”, a w praktyce tylko miesza odpowiedzialności bez realnej korzyści.

Kilka typowych kombinacji:

• VPN + DNS dostawcy VPN
  Domyślny wariant większości klientów. Prosty, spójny, ale:
  • operator VPN widzi i DNS, i ruch IP – pełen obraz tego, co robisz;
  • lokalny ISP widzi jedynie tunel, więc z jego perspektywy prywatność jest rzeczywiście lepsza;
  • jeśli zaufasz złemu VPN, oddajesz mu znacznie więcej niż wcześniej swojemu ISP.
• VPN + własny DoH/DoT (np. Cloudflare, Quad9)
  Popularne wśród bardziej świadomych użytkowników: DNS idzie szyfrowanym kanałem do zewnętrznego resolvera, ale już ze środka tunelu VPN:
  • lokalny ISP nie widzi ani DNS, ani docelowych adresów IP – widzi tylko tunel;
  • dostawca szyfrowanego DNS widzi twoje zapytania, ale przychodzą one z adresu IP VPN, a nie z twojego domowego czy mobilnego – trudniej powiązać je z tobą bezpośrednio;
  • operator VPN nadal widzi adresy IP, do których się łączysz, ale nie zna nazw domen, jeśli wszystko gra po stronie aplikacji/systemu.

  Zaleta: rozdzielenie wiedzy. Nikt pojedynczy nie ma pełnego obrazu:

  • VPN widzi IP i metadane, ale nie widzi DNS (w idealnej konfiguracji);
  • dostawca DNS widzi domeny, ale nie zna twojego realnego IP, tylko IP serwera VPN;
  • lokalny ISP widzi wyłącznie zaszyfrowany tunel.
• VPN + DoH w przeglądarce, a reszta systemu "po staremu"
  Częsty chaos: przeglądarka idzie DoH‑em do jednego dostawcy, inne aplikacje robią DNS do VPN lub do lokalnego routera. Z zewnątrz:
  • część DNS i ruchu HTTP jest widoczna dla VPN, część tylko dla zewnętrznego dostawcy DNS;
  • jeżeli VPN nie wymusza DNS, a lokalny system nadal pyta ISP, możesz zaliczyć DNS leak – ISP dostaje część historii odwiedzanych domen mimo aktywnego VPN;
  • zabezpieczenie staje się trudne do analizy, bo masz trzech równoległych „świadków” tego, co robisz.

Sytuacja, w której łączenie VPN i DoH/DoT szczególnie ma sens, to świadomie zaprojektowany układ: VPN jako „maskowanie IP”, szyfrowany DNS do innego zaufanego podmiotu, konsekwentnie w całym systemie. Działa to zupełnie inaczej niż losowe włączanie przełączników „secure DNS” w przeglądarce i aplikacji VPN jednocześnie.

Co nadal widać mimo VPN, DoH i DoT

Nawet przy „pełnym pakiecie” (VPN + szyfrowany DNS na każdym poziomie) pozostaje zakres informacji, który można odczytać z samych metadanych. To mniej oczywista część modelu zagrożeń.

• Czasy połączeń i objętość danych
  Ktokolwiek widzi twoje połączenie do VPN (np. lokalny ISP) może:
  • odnotować, kiedy zaczynasz i kończysz sesje;
  • oszacować intensywność ruchu (streaming, upload, praca biurowa).

  Sama ta informacja bywa cenna, choć nie zdradza treści ani konkretnych serwisów.

• Wzorce ruchu po drugiej stronie tunelu
  Operator VPN, a czasem podmiot analizujący ruch w Internecie „po stronie serwisów”, widzi:
  • z jakimi adresami IP i ASN rozmawia serwer VPN w twoim imieniu;
  • przybliżony „profil” aktywności: streaming wideo, gry, portale społecznościowe, backupy w chmurze.

  Część z tego da się odgadnąć nawet przy braku logów DNS, korzystając z publicznych baz "IP->usługa".

• Identyfikatory aplikacji i urządzeń
  Samo IP nie jest jedynym identyfikatorem. Gdy:
  • logujesz się do stałych kont (Google, Apple, bank, portale społecznościowe);
  • aplikacje używają stabilnych ID urządzenia lub telemetrii;

  VPN i szyfrowany DNS nie zdejmują z ciebie "odcisku cyfrowego". Zmieniasz tylko część śladu.

Różne role jednej osoby: praca, dom, aktywizm

Jednym z mniej omawianych tematów jest to, że ta sama osoba może potrzebować różnych modeli zaufania w zależności od roli. Przykładowo:

• tryb „pracownik” – korzystasz z korporacyjnego VPN i korporacyjnego DNS; organizacja musi widzieć część rzeczy (bezpieczeństwo, zgodność z przepisami). Próba „ucieczki” na własny VPN lub DoH w przeglądarce może być uznana za naruszenie polityk, a w skrajnych przypadkach osłabić ochronę całej sieci;
• tryb „prywatnie w domu” – inny zestaw narzędzi: własny router z DoT, sensownie dobrany publiczny resolver, czasem lekki VPN na poziomie przeglądarki lub systemu, jeśli chcesz ograniczyć profilowanie przez ISP;
• tryb „wrażliwa aktywność” (np. działalność obywatelska w państwach z niską ochroną praw) – to już inna liga: VPN z przemyślaną jurysdykcją, brak łączenia tożsamości (logowanie do kont prywatnych z tego samego IP), często dodatkowe warstwy typu Tor, system live‑boot, plan awaryjny na wypadek przejęcia urządzenia.

Używanie jednego konta VPN i jednego schematu DNS do wszystkich ról bywa wygodne, ale zaciera granice między tym, co chciałbyś trzymać oddzielnie. Z punktu widzenia prywatności to prośba o korelowanie twoich tożsamości przez jednego, centralnego pośrednika.

Jak nie projektować swojego „stacku prywatności”

Ostatni element układanki to antywzorce – konfiguracje, które wyglądają „technicznie imponująco”, ale z perspektywy modelu zagrożeń są dziurawe lub nadmiarowe.

• „Im więcej warstw, tym lepiej”
  Łączenie:
  • VPN na routerze,
  • drugiego VPN na laptopie,
  • DoH w przeglądarce,
  • DoT w systemie,

  często kończy się:

  • trudnymi do wykrycia wyciekami DNS (jedna warstwa nie wie, co robi druga);
  • dziwnymi problemami z wydajnością i stabilnością połączeń;
  • fałszywym poczuciem bezpieczeństwa: „mam pięć warstw, więc na pewno nikt nic nie widzi”.

  Lepszy jest jeden, spójny plan niż stos przypadkowo nałożonych technologii.

Najważniejsze punkty

• Najwięcej o użytkowniku mówią metadane (domeny, IP, czas i częstotliwość połączeń, wolumen ruchu), a nie sama treść wiadomości czy stron; z dłuższej perspektywy to one pozwalają odtworzyć styl życia, nawyki i zainteresowania.
• Szyfrowanie HTTPS, DNS over HTTPS/TLS czy VPN z reguły chroni treść, ale nie usuwa metadanych – one nadal są widoczne dla różnych podmiotów na trasie pakietu, tylko przesuwają się między nimi.
• Każda warstwa komunikacji (DNS, IP/porty, TLS, VPN) daje inny „widok” na twoją aktywność: DNS ujawnia domeny, IP pokazuje adresy i porty, TLS częściowo domenę, a VPN jedynie to, że łączysz się szyfrowanym tunelem do konkretnego serwera.
• Przejście na DNS over HTTPS lub DNS over TLS nie „chowa” zapytań DNS przed wszystkimi, ale przenosi pełną wiedzę o odwiedzanych domenach z twojego ISP do zewnętrznego operatora DNS (np. Cloudflare czy Google).
• VPN nie czyni cię anonimowym w magiczny sposób – ogranicza wgląd ISP i lokalnej sieci (np. w kawiarni), ale za to centralizuje wiedzę u dostawcy VPN, który widzi docelowe IP, wzorce ruchu i często również logi DNS.
• Typowa „bezpieczna rada” w stylu „włącz VPN i DNS over HTTPS, a jesteś ukryty” działa tylko częściowo: nadal zostawiasz ślady u operatora VPN, dostawcy DNS i właścicieli serwisów, więc realna poprawa zależy od tego, którym z nich ufasz.