Important
Zastrzeżenie. To jest opis mojego własnego przypadku, spisany po tym, jak sam przez to przeszedłem. Nie jest to materiał oficjalny: nie powstał we współpracy z WDM ani żadnym innym operatorem, nie został przez nikogo z nich potwierdzony ani zatwierdzony, i nie wypowiadam się w niczyim imieniu.
Nie twierdzę też, że każdy klient tego operatora ma ten sam problem, ani że przyczyna leży dokładnie tam, gdzie ją obstawiam — opisuję objawy, które u siebie zaobserwowałem, oraz obejście, które u mnie zadziałało. Wnioski o przechwytywaniu UDP/53 wyciągnąłem z zachowania własnego łącza, nie z żadnego oficjalnego źródła.
Konkretnie chodzi o łącze WDM Sp. z o.o. (Mielec, podkarpackie). Sprawdź najpierw u siebie (patrz „Szybka diagnoza" niżej) i korzystaj na własną odpowiedzialność. Jeśli u Ciebie objawy albo rozwiązanie wyglądają inaczej — daj znać, chętnie poprawię.
Internet niby działa (adresy IP pingują się normalnie), ale nazwy domen przestają się rozwiązywać — losowo albo na dłuższe okresy:
C:\> ping google.pl
Ping request could not find host google.pl. Please check the name and try again.
C:\> nslookup google.pl
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out
Przy czym same serwery DNS są osiągalne:
C:\> ping 1.1.1.1
Reply from 1.1.1.1: bytes=32 time=7ms TTL=57
Ustawienie "lepszych" serwerów DNS (1.1.1.1, 8.8.8.8) w ustawieniach karty sieciowej nic nie daje — i to jest właśnie kluczowa wskazówka.
Wykonaj te dwa polecenia (cmd lub PowerShell):
nslookup google.pl 1.1.1.1
nslookup -vc google.pl 1.1.1.1
Jeśli pierwsze się wysypuje, a drugie działa — masz dokładnie ten problem. Przełącznik -vc wymusza zapytanie DNS po TCP zamiast po UDP.
Wniosek: ruch DNS po UDP na porcie 53 jest przechwytywany i przekierowywany na resolwery operatora (które bywają martwe), natomiast ten sam ruch po TCP przechodzi bez przeszkód. Dlatego zmiana serwera DNS w Windows nic nie zmienia — pakiety i tak nigdy nie docierają tam, gdzie je wysyłasz.
Zanim zaczniesz: upewnij się, że winowajcą nie jest klient VPN (Tailscale, WARP, firmowy VPN itp.) — takie programy potrafią podmieniać DNS na swoje. Wyłącz je na próbę i powtórz test powyżej.
Tip
Masz Windows 11? Zacznij od czegoś prostszego. Windows 11 ma wbudowaną obsługę szyfrowanego DNS (DNS-over-HTTPS), której Windows 10 w wersji konsumenckiej nie dostał — konfiguruje się ją klikając, w Ustawienia → Sieć i Internet → (Twoje połączenie) → Przypisanie serwera DNS → Edytuj, gdzie dochodzi opcja szyfrowania (m.in. „Tylko szyfrowane"). DoH chodzi po porcie 443, więc omija przechwytywanie UDP/53 dokładnie tak samo jak opisany tu Unbound — tyle że bez instalowania czegokolwiek. Jeśli to zadziała, cała reszta tej instrukcji jest Ci niepotrzebna. Unbound zostaje rozwiązaniem dla Windows 10 (i dla tych, którzy wolą własny resolver z cache'em i walidacją DNSSEC).
Postawić na komputerze lokalny resolver DNS, który:
- lokalnie odpowiada normalnie po UDP i TCP na
127.0.0.1:53— więc wszystkie programy w systemie działają bez zmian, - w górę odpytuje publiczne serwery przez DNS-over-TLS na porcie 853 (TCP) — czyli po ścieżce, której przechwytywanie nie dotyczy, a przy okazji szyfrowanej.
Użyjemy do tego Unbound — otwartoźródłowy, lekki, bez zakładania konta, z natywną wersją na Windows.
Alternatywy, które odpadają:
- cloudflared — tryb
proxy-dns(lokalne proxy DoH) został usunięty z wydań cloudflared 2 lutego 2026, aktualne wersje tego po prostu nie potrafią, - Cloudflare WARP — działa, ale wymaga rejestracji konta,
- wyłączenie firewalla Windows / grzebanie w rejestrze (
TcpQueryIpsecPolicyitp.) — sprawdzone, nie pomaga, bo problem jest poza komputerem.
Pobierz instalator ze strony https://nlnetlabs.nl/projects/unbound/download/ i zainstaluj (domyślnie ląduje w C:\Program Files\Unbound\). Instalator sam rejestruje usługę Windows.
Note
Nie przestrasz się niebieskiego okna przy uruchamianiu instalatora. Windows pokaże ostrzeżenie SmartScreen — „System Windows chronił Twój komputer" — i na pierwszy rzut oka wygląda, jakby nie dało się nic zrobić, bo widać tylko przycisk Nie uruchamiaj. Trzeba kliknąć „Więcej informacji", a dopiero wtedy pojawi się „Uruchom mimo to".
To ostrzeżenie nie znaczy, że w pliku wykryto wirusa. SmartScreen zgłasza tak każdy program, który nie jest podpisany drogim certyfikatem i nie został jeszcze pobrany przez odpowiednio wielu użytkowników — a Unbound to niszowe narzędzie od niekomercyjnej fundacji, więc siłą rzeczy nie zbiera takiej „reputacji" jak instalator popularnej przeglądarki.
Skoro jednak klikasz „mimo to", to warto mieć pewność, co uruchamiasz: pobieraj wyłącznie z oficjalnej strony NLnet Labs podlinkowanej wyżej (adres musi się zgadzać, połączenie po HTTPS), nie z przypadkowych „downloadów". Jeśli chcesz, obok plików do pobrania są sumy kontrolne i podpisy PGP do weryfikacji.
Uwaga, tu jest pułapka: usługa Unbound na Windows czyta plik service.conf, a nie unbound.conf. Plik unbound.conf położony w tym samym katalogu zostanie po cichu zignorowany.
Plik trzeba otworzyć jako administrator — leży w Program Files, więc bez tego nie zapiszesz zmian (Notatnik pozwoli edytować, ale przy zapisie wyświetli błąd odmowy dostępu). Po kolei:
- Kliknij Start i wpisz
notatnik(albonotepad). - Na znalezionym Notatniku kliknij prawym przyciskiem → Uruchom jako administrator. Potwierdź monit UAC.
- W Notatniku wybierz Plik → Otwórz (albo
Ctrl+O). - W polu Nazwa pliku wklej pełną ścieżkę i naciśnij Enter:
C:\Program Files\Unbound\service.conf
Wklejenie pełnej ścieżki jest tu istotne: Notatnik domyślnie pokazuje tylko pliki *.txt, więc service.conf w ogóle nie pojawi się na liście, choć istnieje. Możesz też zamiast tego przestawić filtr w prawym dolnym rogu okna z „Dokumenty tekstowe" na „Wszystkie pliki".
Ustaw zawartość pliku tak:
server:
# 0 = tylko błędy. Jeśli coś nie działa, podnieś na 2 (lub więcej) i zrestartuj usługę — w logu widać wtedy przebieg zapytań.
verbosity: 0
logfile: "C:\Program Files\Unbound\unbound.log"
# KLUCZOWE: korzystaj z magazynu certyfikatów Windows
tls-win-cert: yes
do-udp: yes
do-tcp: yes
tcp-upstream: yes
auto-trust-anchor-file: "C:\Program Files\Unbound\root.key"
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 1.1.1.1@853#one.one.one.one
forward-addr: 8.8.8.8@853#dns.google
Wcięcia muszą być zrobione tabulatorami lub spacjami — byle konsekwentnie.
W PowerShellu jako administrator:
& "C:\Program Files\Unbound\unbound-checkconf.exe" "C:\Program Files\Unbound\service.conf"
Restart-Service unboundunbound-checkconf powinien odpowiedzieć no errors.
Szybki test, czy resolver już działa:
nslookup google.com 127.0.0.1Przez GUI: Panel sterowania → Centrum sieci i udostępniania → Zmień ustawienia karty sieciowej → prawy klik na karcie → Właściwości → Protokół internetowy w wersji 4 (TCP/IPv4) → Właściwości → Użyj następujących adresów serwerów DNS → preferowany: 127.0.0.1, alternatywny: 1.1.1.1 (albo inny, który lubisz).
Albo z PowerShella jako administrator. Najprościej ustawić od razu wszystkie karty fizyczne, bez wpisywania nazw:
Get-NetAdapter -Physical | Set-DnsClientServerAddress -ServerAddresses 127.0.0.1,1.1.1.1
ipconfig /flushdnsJeśli wolisz wskazać konkretną kartę, najpierw sprawdź, jak się u Ciebie nazywa — nazwy kart u każdego są inne, zależą od sprzętu, wersji i języka systemu, bywa też "Ethernet 2" czy "Sieć bezprzewodowa":
Get-NetAdapter -Physical | Format-Table Name, Status
Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses 127.0.0.1,1.1.1.1Dwie rzeczy, na które trzeba uważać:
-
Ustaw to na wszystkich kartach, których używasz, a nie tylko na tej aktywnej w danej chwili — dlatego powyżej jest wariant "wszystkie naraz". Bardzo łatwo tu zmarnować pół godziny: ustawisz
127.0.0.1na "Ethernet", a faktycznie jesteś na Wi-Fi, więc system dalej używa DNS-a z DHCP od routera i wygląda to jakby poprawka nie zadziałała. Statyczny DNS przeżywa odłączenie kabla, więc spokojnie można ustawić z góry również kartę aktualnie nieaktywną. -
Serwer zapasowy to świadomy kompromis — warto rozumieć, co się wybiera:
- Z zapasowym (
127.0.0.1+1.1.1.1): jeśli usługa Unbound padnie albo jej nie uruchomisz, nazwy nadal będą się rozwiązywać — wprawdzie po starej, przechwytywanej ścieżce UDP, ale to wciąż lepsze niż całkowity brak DNS-u. Minusem jest to, że Windows potrafi zsunąć się na serwer zapasowy również wtedy, gdy ten pierwszy tylko zwleka z odpowiedzią (np. przy zimnym starcie i nawiązywaniu sesji TLS). Wtedy część zapytań po cichu idzie znów przez operatora, a Ty się o tym nie dowiesz. - Bez zapasowego (samo
127.0.0.1): masz gwarancję, że każde zapytanie idzie przez Unbounda i szyfrowanym kanałem. Za to gdy usługa nie działa, DNS nie działa w ogóle — objaw jest głośny i od razu wiadomo, gdzie szukać.
Dla świętego spokoju polecam wariant z zapasowym. Jeśli natomiast zależy Ci, żeby nic nie wyciekało poza szyfrowany kanał — zostaw samo
127.0.0.1i sprawdzaj, czy usługaunboundstartuje automatycznie. - Z zapasowym (
# Czy karty wskazują na lokalny resolver:
Get-DnsClientServerAddress -AddressFamily IPv4 | Where-Object {$_.ServerAddresses} | Format-Table InterfaceAlias, ServerAddresses
# Czy nazwy się rozwiązują normalnie (po UDP, lokalnie):
nslookup google.com
ping google.pl
# Dowód, że w górę faktycznie idzie DoT — powinny być połączenia na port 853:
Get-NetTCPConnection -RemotePort 853 | Format-Table LocalAddress, RemoteAddress, State
# Nie powinno nic wypisać:
Get-Content "C:\Program Files\Unbound\unbound.log" -Tail 200 | Select-String "ssl handshake|certificate"Warning
Kolejność ma znaczenie: najpierw przestaw DNS z powrotem, potem zatrzymaj usługę. Jeśli zrobisz odwrotnie, karty sieciowe będą wskazywać na 127.0.0.1, pod którym nikogo już nie ma — i zostaniesz bez działającego DNS-u w ogóle.
# Powrót do serwerów podawanych przez DHCP (czyli operatora):
Get-NetAdapter -Physical | Set-DnsClientServerAddress -ResetServerAddresses
ipconfig /flushdnsPamiętaj, że to znaczy powrót do punktu wyjścia — jeśli problem z przechwytywaniem UDP/53 nadal istnieje, wróci razem z tym ustawieniem.
Stop-Service unbound
Set-Service unbound -StartupType Manual # nie wystartuje sam przy starcie systemuŻeby wrócić do korzystania z Unbounda, wystarczy odwrócić oba kroki:
Set-Service unbound -StartupType Automatic
Start-Service unbound
Get-NetAdapter -Physical | Set-DnsClientServerAddress -ServerAddresses 127.0.0.1,1.1.1.1Ustawienia → Aplikacje → Aplikacje i funkcje → Unbound → Odinstaluj, albo uruchom C:\Program Files\Unbound\uninst.exe. Deinstalator usuwa też usługę z systemu.
Po deinstalacji może zostać katalog C:\Program Files\Unbound\ z plikami, których instalator nie zakładał — własny service.conf, kopie zapasowe i unbound.log. Jeśli chcesz posprzątać do końca, skasuj go ręcznie.
Sprawdzenie, czy nic nie zostało:
Get-Service unbound -ErrorAction SilentlyContinue # nie powinno nic zwrócić
Get-DnsClientServerAddress -AddressFamily IPv4 | Where-Object {$_.ServerAddresses} | Format-Table InterfaceAlias, ServerAddresses
nslookup google.comPrzy pierwszym zapytaniu po starcie widzę DNS request timed out, ale odpowiedź i tak przychodzi. To normalne — pierwsze nawiązanie sesji TLS nie mieści się w 2-sekundowym limicie nslookup. Przy kolejnych zapytaniach, gdy sesja TLS jest już zestawiona, komunikat znika.
Czy to spowalnia internet? Nie zauważalnie. Sesja TLS jest utrzymywana, a Unbound cache'uje odpowiedzi, więc w praktyce bywa nawet szybciej niż wcześniej.
Podłączyłem się do nowej sieci / doszła nowa karta i znowu nie działa. Nowa karta dostanie DNS z DHCP, czyli znów operatora. Trzeba jej ustawić 127.0.0.1 tak samo jak pozostałym.
Log rośnie. Przy verbosity: 2 (tak bywa domyślnie po instalacji) plik unbound.log potrafi urosnąć o setki kB w zwykłym użyciu. Dlatego w konfiguracji powyżej jest 0 — same błędy. Jeśli coś nie działa, podnieś na 2 lub wyżej, zrestartuj usługę i zajrzyj do logu.
Przy okazji dostajesz walidację DNSSEC — dzięki auto-trust-anchor-file z root.key Unbound sprawdza podpisy DNSSEC, czego systemowy resolver Windows domyślnie nie robi.
Czy zwiększa to zużycie zasobów komputera? Trochę tak — cache nie bierze się z powietrza. U mnie proces unbound.exe zajmuje ok. 20 MB pamięci (z czego ok. 7 MB to pamięć prywatna) i poniżej sekundy czasu procesora na kilkanaście minut pracy, czyli praktycznie zero. W skali dzisiejszego komputera to niezauważalne, ale warto wiedzieć, że to jest stale działająca usługa, a nie magia. Jeśli zależy Ci na każdym megabajcie, rozmiar cache'u można ograniczyć w sekcji server::
msg-cache-size: 4m
rrset-cache-size: 8m
W drugą stronę: na maszynie z zapasem RAM-u zwiększenie tych wartości daje więcej trafień w cache i mniej zapytań na zewnątrz.
Czy to obejście jest legalne? Konfiguracja własnego resolvera na własnym komputerze to zwykłe korzystanie ze standardowego, publicznego protokołu na własnym sprzęcie — tu nie ma czego naruszać. Ruch DoT wygląda jak zwykłe połączenie TLS na porcie 853.
Ciekawsze jest pytanie odwrotne — czy legalne jest przechwytywanie zapytań DNS przez operatora. Rozporządzenie (UE) 2015/2120 (neutralność sieci) w art. 3 nakazuje dostawcom traktować cały ruch równo, bez dyskryminacji i ingerencji, a dopuszczalne środki zarządzania ruchem muszą być uzasadnione, proporcjonalne i przejrzyste. Warto przy tym pamiętać, że nie każde przekierowanie DNS jest nadużyciem: blokowanie domen z Listy Ostrzeżeń CERT/NASK jest realizowane właśnie na poziomie DNS, w ramach porozumienia z UKE, i jest jawne oraz udokumentowane.
Ciche przekierowywanie całego ruchu UDP/53 na własne resolwery to jednak co innego niż blokada konkretnych, ogłoszonych domen — zwłaszcza gdy te resolwery bywają niedostępne. Czy w konkretnym przypadku jest to naruszenie, nie rozstrzygnę i nie jest to porada prawna; właściwa droga to reklamacja u operatora, a jeśli nie pomoże — skarga do UKE. Ta instrukcja rozwiązuje objaw, nie przyczynę.
Czy operator może zablokować także DoT? Technicznie tak — wystarczy zablokować port 853. Gdyby tak się stało, pozostaje DNS-over-HTTPS (port 443), którego blokowanie jest znacznie trudniejsze, bo ruch jest nieodróżnialny od zwykłego HTTPS. Windowsowy Unbound nie ma jednak wkompilowanej obsługi DoH — trzeba by wtedy sięgnąć po inne narzędzie.
Testowane na Windows 10 Home 22H2 (build 19045) — i tylko tam. Na Windows 11 kroki powinny być podobne (ten sam instalator, ta sama usługa, te same polecenia PowerShella), ale tego nie sprawdzałem; na pewno różnią się ścieżki w GUI ustawień sieci. Jeśli ktoś przejdzie to na Windows 11, chętnie poznam wynik — uzupełnię instrukcję.