Optymalizacja DNS i TCP/IP: szybszy internet bez zmiany operatora

Jak faktycznie działa „szybki internet”: opóźnienie, przepustowość, straty

Przepustowość z umowy a odczuwalna szybkość

Operator sprzedaje łącze w megabitach na sekundę. Ten parametr mówi, ile danych maksymalnie może przepłynąć w czasie, gdy już istnieje połączenie i nic go szczególnie nie spowalnia. Nie mówi natomiast, jak szybko otworzy się pierwsza strona, jak szybko zareaguje gra online ani ile czasu minie od kliknięcia linku do pojawienia się treści.

Odczuwalna szybkość to przede wszystkim czas reakcji: jak szybko następuje odpowiedź po żądaniu. Najpierw adres musi zostać przetłumaczony przez DNS, potem zestawia się połączenie TCP, następnie trwa negocjacja HTTPS, a dopiero na końcu leci właściwy transfer danych. Każdy z tych etapów to kolejne dziesiątki lub setki milisekund. Jeśli w kilku miejscach jest opóźnienie, sumuje się ono w wyraźne „muli”.

Dlatego na komputerze z łączem 1 Gbit/s strona może ładować się wolniej niż na innym z łączem 300 Mbit/s. Jeżeli pierwszy ma kiepsko dobrany DNS i nieoptymalne parametry TCP/IP, a drugi korzysta z lokalnego cache DNS i dobrze dostrojonego stosu sieciowego, subiektywne wrażenie szybkości będzie odwrotne niż wskazują cyferki w umowie.

Opóźnienie, jitter, utrata pakietów – co naprawdę spowalnia

Opóźnienie (latency) to czas, jaki mija od wysłania pakietu do otrzymania odpowiedzi. Dla użytkownika przekłada się to na moment, w którym coś zaczyna się dziać po kliknięciu. Im wyższe opóźnienie, tym dłużej czeka się na start ładowania strony, rozpoczęcie pobierania pliku czy reakcję serwera w grze.

Jitter to zmienność opóźnienia – raz pakiet dociera po 20 ms, raz po 80 ms. Dla przeglądania stron jest to umiarkowany problem, ale dla gier online, VoIP czy wideokonferencji ma ogromne znaczenie. Nieregularne opóźnienia powodują zacinanie głosu, teleportowanie postaci w grach i pobijanie buforów w odtwarzaczach wideo na żywo.

Utrata pakietów oznacza, że część danych po drodze ginie i musi zostać wysłana ponownie (TCP) lub przepada (UDP). W TCP retransmisje gwałtownie zmniejszają realną przepustowość, bo protokół interpretuje je jako przeciążenie sieci i zwalnia. Na wykresach speedtestu wygląda to często jak „ząbki” albo nagłe spadki transferu w trakcie testu.

DNS i TCP/IP dotykają wszystkich tych elementów: DNS wpływa na czas startu połączenia, a parametry TCP/IP – na to, jak efektywnie dane płyną przy danym opóźnieniu i jakości łącza. Dobre ustawienia nie naprawią fizycznej awarii kabla, ale potrafią skrócić odczuwalny czas ładowania o dziesiątki procent na zdrowym, lecz źle skonfigurowanym łączu.

Typowe objawy złej konfiguracji przy dobrym łączu

Często pojawia się podobny schemat: speedtest pokazuje świetne wartości, ale codzienne korzystanie z sieci jest frustrujące. Najczęstsze sygnały:

• speedtest pokazuje wysoki download i upload, ale strony startują z opóźnieniem, długo widać „szare” okno przeglądarki zanim pojawi się pierwszy tekst;
• gry online mają stabilny ping w teście, ale w realnej rozgrywce zdarzają się krótkie lagi i „przeskoki”;
• niektóre strony otwierają się bardzo wolno lub wcale, inne działają bez problemu;
• VPN działa niestabilnie, rozłącza lub „wisi” przy niektórych usługach.

W wielu takich przypadkach winne są właśnie:
zbyt wolne lub niestabilne serwery DNS, nieprawidłowy MTU/MSS powodujący fragmentację pakietów oraz niezoptymalizowane bufory i algorytmy TCP po stronie systemu lub routera. Wszystko to można poprawić bez zmiany operatora i sprzętu, wykorzystując wyłącznie konfigurację.

DNS w praktyce: co dzieje się, zanim otworzy się strona

Rola DNS w każdym połączeniu HTTP/HTTPS

Za każdym razem, gdy wpisujesz adres typu example.com, system musi go przetłumaczyć na adres IP. Realnie wygląda to tak:

1. Przeglądarka pyta system: „jaki jest adres IP dla example.com?”
2. System sprawdza lokalny cache DNS – jeśli tam nie ma, pyta skonfigurowany serwer DNS (operatora, publiczny lub lokalny).
3. Serwer DNS, jeśli też nie ma w cache, robi zapytanie rekurencyjne przez kolejne serwery (root, TLD, autorytatywny) aż znajdzie właściwy rekord.
4. Adres IP wraca do systemu, trafia do przeglądarki i dopiero wtedy może zostać nawiązane pierwsze połączenie TCP do serwera.

Ten etap jest kompletnie niewidoczny dla przeciętnego użytkownika, ale wykonuje się dla każdego nowego hosta (współczesne strony korzystają z dziesiątek domen: czcionki, analityka, CDN, reklamy, API). Jeśli DNS odpowiada wolno, opóźnienie kumuluje się i strona zanim zacznie coś ładować, już straciła sporo czasu.

Czas odpowiedzi DNS a TTFB

TTFB (Time To First Byte) to czas od wysłania żądania HTTP(S) do otrzymania pierwszego bajtu odpowiedzi z serwera. Użytkownik widzi to jako moment, gdy przeglądarka z „oczekuję” przechodzi do „zaczynam pobierać dane”. TTFB obejmuje:

• czas DNS (jeśli nie ma wpisu w cache);
• czas nawiązania połączenia TCP (trzyetapowy handshake);
• czas negocjacji TLS/HTTPS;
• czas przetwarzania żądania po stronie serwera.

Jeżeli sam DNS zabiera 150–300 ms, to nawet szybki serwer WWW i dobre łącze nie pomogą – TTFB rośnie, a strona wydaje się ociężała. Zmiana DNS na szybszy potrafi obciąć ten składnik do kilkunastu–kilkudziesięciu ms. Na pojedynczej stronie różnica wydaje się niewielka, ale przy kilkudziesięciu domenach i codziennym korzystaniu z sieci daje bardzo wyraźny efekt.

Rekurencyjne serwery DNS, cache i TTL

Rekurencyjny serwer DNS to ten, który obsługuje zapytania użytkownika końcowego i – jeśli nie ma odpowiedzi – dopytuje dalej inne serwery. Może to być DNS operatora, Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9) lub lokalny serwer w sieci domowej (np. dnsmasq, unbound).

Każda odpowiedź DNS ma parametr TTL (Time To Live) – ile sekund można ją przechowywać w cache. Przeglądarka ma swój cache, system ma swój, rekurencyjny serwer – również. Im bliżej użytkownika następuje trafienie z cache, tym szybciej odbywa się rozwiązywanie nazwy. Dlatego lokalny cache DNS na routerze lub komputerze potrafi mocno skrócić czas reakcji przy często odwiedzanych stronach.

DNS operatora zwykle ma dobry cache dla popularnych serwisów, ale bywa przeciążony, źle skonfigurowany, a czasem wręcz filtrowany pod kątem reklam czy blokad. Publiczne DNS oferują zwykle lepszą stabilność i dodatkowe funkcje, ale ich fizyczna odległość i trasa pakietów mogą podnosić opóźnienie. Lokalne resolvery (na routerze lub serwerze domowym) dają największą kontrolę, ale wymagają podstawowej administracji.

DNS operatora, publiczne serwery i lokalny resolver

Do dyspozycji są trzy główne warianty:

• DNS operatora – domyślne, działa „z pudełka”, często ma krótką drogę sieciową, bo znajduje się w infrastrukturze ISP. Słabe strony: niestabilność, brak wsparcia DoH/DoT, czasem cicha cenzura lub „podmiana” błędnych adresów na strony z reklamami.
• Publiczne DNS (Google, Cloudflare, Quad9 i inne) – zwykle bardziej stabilne, lepsze wsparcie dla nowoczesnych funkcji, czasem filtracja złośliwych domen. Zależne jednak od tras między operatorem a danym dostawcą – w jednej lokalizacji będą świetne, w innej mogą mieć gorsze opóźnienia niż DNS lokalnego ISP.
• Lokalny resolver z cache (np. dnsmasq, unbound na routerze) – po pierwszym odpytywaniu zewnętrznego DNS zapamiętuje odpowiedź i przy kolejnych zapytaniach zwraca ją z pamięci w kilka milisekund. Pozwala też wdrożyć lokalne reguły (blokady reklam, mapowanie domen na lokalne IP, split-DNS dla VPN).

Największe korzyści w typowej sieci domowej daje połączenie: szybki, stabilny zewnętrzny DNS + lokalny cache na routerze lub serwerze domowym. Konfiguracja jest prosta, a zyski widoczne już po kilku minutach testów.

Wybór szybszego DNS: narzędzia i testy zamiast zgadywania

Dlaczego „modny DNS” nie zawsze jest najlepszy

W sieci regularnie pojawiają się hasła typu „przestaw DNS na 1.1.1.1 / 8.8.8.8 i będzie szybciej”. Czasem to prawda, ale bywa też odwrotnie. Szybkość DNS zależy od:

• fizycznej odległości od serwera i trasy w sieci operatora,
• obciążenia konkretnego węzła (anycast nie zawsze trafia do najbliższego),
• kondycji węzłów pośrednich (routery, przełączniki, peeringi między operatorami),
• lokalnych polityk routingu i priorytetów ruchu.

W jednym mieście DNS operatora może odpowiadać w 8 ms, a Google DNS w 25 ms. W innym miejscu – na odwrót. Dlatego zamiast ślepo kopiować ustawienia z poradnika wideo, lepiej poświęcić 10–20 minut na wiarygodny test i dobrać DNS na podstawie realnych pomiarów.

Narzędzia do testowania: DNS Benchmark, Namebench, polecenia systemowe

Do sprawdzenia szybkości i stabilności DNS można użyć zarówno specjalnych programów, jak i prostych narzędzi wbudowanych w system.

DNS Benchmark (Windows)

DNS Benchmark (Gibson Research) to niewielki program dla Windows, który:

• ma wbudowaną listę popularnych serwerów DNS,
• mierzy czas odpowiedzi każdego z nich dla wielu domen,
• pokazuje wyniki w formie wykresów i tabel,
• pozwala dodać własne serwery, np. DNS operatora.

Po uruchomieniu warto:

1. Dodać adresy DNS obecnie skonfigurowane w routerze/komputerze.
2. Uruchomić pełny benchmark i poczekać na zakończenie (kilkanaście minut).
3. Na podstawie wyników wybrać 2–3 najlepsze serwery – najszybsze i najbardziej stabilne.

Namebench (Windows, Linux, macOS)

Namebench (czasem wymaga ręcznej instalacji z repozytoriów lub z GitHuba) działa podobnie: generuje listę potencjalnych serwerów DNS, wykonuje wiele zapytań i wskazuje najlepsze w danej lokalizacji. Przydatny szczególnie tam, gdzie nie ma DNS Benchmark w natywnej wersji.

dig, nslookup i testy online

Na Linux, macOS i WSL przydaje się dig (z pakietu dnsutils lub podobnego). Przykład:

dig @1.1.1.1 example.com +stats

Wynik zawiera czas odpowiedzi w milisekundach. Podobnie można przetestować ten sam adres domeny dla kilku różnych serwerów, np. operatora, Google, Cloudflare, Quad9. Prosta procedura:

1. Wybierz 5–7 serwerów DNS do testu (2 operatora, 2–3 publiczne, 1–2 niszowe).
2. Dla każdej domeny (np. popularne portale, serwisy globalne) wykonaj po kilka zapytań dig dla każdego DNS.
3. Porównaj średnie czasy odpowiedzi i zwróć uwagę na stabilność (czy czasy są zbliżone, czy mocno się wahają).

Dodatkowo istnieją strony WWW, które testują DNS od strony przeglądarki. Przydatne do szybkiego porównania, ale mniej precyzyjne niż narzędzia lokalne, ponieważ dochodzi narzut środowiska przeglądarkowego.

Jak interpretować wyniki: czas, stabilność, prywatność

Przy wyborze DNS warto ocenić kilka parametrów:

• Średni czas odpowiedzi – im niższy, tym lepiej. Dla sieci domowej wartości rzędu 5–30 ms są bardzo dobre, powyżej 50–60 ms zaczyna być czuwalne opóźnienie.
• Stabilność – czy kolejne zapytania mają podobne czasy, czy są duże „skoki”. Lepiej wybrać serwer ciut wolniejszy, ale stabilny, niż najszybszy w jednym teście i bardzo nierówny w dłuższej perspektywie.
• Dostępność – czy w testach pojawiają się timeouty. Nawet sporadyczne braki odpowiedzi potrafią powodować wrażenie losowych zawieszeń stron.
• Prywatność i bezpieczeństwo – polityka logów, wsparcie DNSSEC, dostępność DNS-over-HTTPS (DoH) oraz DNS-over-TLS (DoT), opcjonalne filtrowanie złośliwych domen.

Testowanie DNS w realnych warunkach przeglądarki

Pomiary z dig czy DNS Benchmark są dobrym punktem startu, ale liczy się to, jak zachowuje się DNS podczas normalnego korzystania z sieci. Kilka prostych testów pozwala wychwycić problemy, których nie widać w syntetycznych benchmarkach.

• Test „pierwszego wejścia” – wyczyść cache DNS systemu i przeglądarki, uruchom narzędzia deweloperskie (zakładka Network), otwórz kilka cięższych serwisów i sprawdź kolumnę „Waiting / DNS”. Porównaj wyniki dla różnych konfiguracji DNS.
• Test „codziennego użycia” – na wybranym DNS korzystaj normalnie z sieci przez dzień lub dwa. Zwróć uwagę na sporadyczne „zawieszki” i komunikaty „wyszukiwanie hosta…”. Jeżeli przy kolejnym DNS te same strony otwierają się płynniej, liczby z benchmarku nie oddają całego obrazu.
• Test w godzinach szczytu – wieczorem, gdy obciążenie sieci jest największe, powtórz pomiary. Część serwerów DNS „klęka” właśnie wtedy, choć w benchmarku z południa wyglądała dobrze.

Dobry DNS powinien wypadać poprawnie we wszystkich trzech scenariuszach. Jeżeli świetnie wygląda w jednym, a w dwóch pozostałych zawodzi – szukaj dalej.

Konfiguracja DNS na poziomie systemu: Windows, Linux, macOS, Android

Ogólna strategia konfiguracji

Zmiana DNS na poziomie systemu przydaje się, gdy:

• nie masz dostępu do routera (np. sieć w pracy, akademiku),
• router od operatora ignoruje ręczne ustawienia DNS lub je nadpisuje,
• chcesz testować różne DNS tylko na jednym urządzeniu.

W każdym systemie logika jest podobna: edytujesz konfigurację interfejsu sieciowego (Wi-Fi / Ethernet), odznaczasz automatyczne pobieranie DNS (DHCP) i wpisujesz ręcznie 1–2 adresy serwerów.

Windows 10 / 11

W nowszych Windowsach są dwa podejścia: klasyczny Panel sterowania i nowe Ustawienia. Klasyczny sposób jest bardziej precyzyjny.

Zmiana DNS przez Panel sterowania

1. Otwórz ncpa.cpl (Win+R → wpisz ncpa.cpl).
2. Kliknij prawym przyciskiem aktywne połączenie (Ethernet lub Wi-Fi) → Właściwości.
3. Zaznacz Protokoł internetowy w wersji 4 (TCP/IPv4) → Właściwości.
4. Zaznacz Użyj następujących adresów serwerów DNS.
5. Wpisz preferowany i alternatywny DNS (np. 1.1.1.1 i 1.0.0.1 lub adresy z benchmarku).
6. Zatwierdź zmiany, rozłącz i połącz ponownie sieć (lub ipconfig /flushdns w CMD).

Jeśli korzystasz z IPv6 i Twój dostawca go obsługuje, analogicznie ustaw TCP/IPv6, wpisując odpowiednie adresy DNS (np. dla Cloudflare: 2606:4700:4700::1111 i 2606:4700:4700::1001).

Ustawienia DoH w Windows 10/11

Windows obsługuje DNS-over-HTTPS na poziomie systemu, ale wymaga dodania konkretnego dostawcy.

1. Wejdź w Ustawienia → Sieć i Internet → Zmień właściwości adaptera (lub analogicznie w zależności od wersji).
2. Wybierz połączenie → Edytuj przy „Ustawienia IP”.
3. Przełącz na Ręczne, włącz IPv4.
4. Wprowadź adresy DNS (np. 1.1.1.1 i 1.0.0.1).
5. Z listy „Szyfrowanie DNS” wybierz Preferuj szyfrowany lub Tylko szyfrowany.

Nie wszyscy dostawcy są rozpoznawani automatycznie. Lista wspieranych serwerów DoH jest ograniczona; przed konfiguracją sprawdź aktualną dokumentację Microsoftu.

Linux (NetworkManager, systemd-resolved, konfiguracja ręczna)

Na desktopowych dystrybucjach zwykle działa NetworkManager, który zarządza DNS dla interfejsów. Najwygodniej zmienić DNS właśnie tam.

NetworkManager (GUI – GNOME, KDE, inne)

1. Kliknij ikonę sieci → Ustawienia sieci / Edytuj połączenia.
2. Wybierz aktywne połączenie (kablowe / Wi-Fi) → Ustawienia.
3. Przejdź do zakładki IPv4.
4. Tryb „Automatyczny (DHCP)” pozostaw dla adresu IP, ale w polu DNS wpisz ręcznie listę serwerów, rozdzielając je przecinkami lub spacjami (zależnie od GUI).
5. Zapisz, rozłącz i połącz sieć.

NetworkManager (CLI – nmcli)

Dla serwera bez GUI wygodniej użyć nmcli:

nmcli con show          # lista połączeń
nmcli con mod <nazwa> ipv4.dns "1.1.1.1 1.0.0.1"
nmcli con mod <nazwa> ipv4.ignore-auto-dns yes
nmcli con down <nazwa> && nmcli con up <nazwa>

Analogicznie skonfigurujesz IPv6 (ipv6.dns, ipv6.ignore-auto-dns).

systemd-resolved i /etc/systemd/resolved.conf

W nowszych dystrybucjach systemd-resolved działa jako lokalny stub resolver. Zmiana DNS polega na edycji jego konfiguracji:

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4
DNSSEC=yes
# opcjonalnie: DNSOverTLS=yes

Po zmianie:

sudo systemctl restart systemd-resolved

Ręczna edycja /etc/resolv.conf

Stary, „ręczny” sposób to modyfikacja /etc/resolv.conf:

nameserver 1.1.1.1
nameserver 1.0.0.1

W wielu systemach ten plik jest nadpisywany przez NetworkManager lub systemd-resolved. Jeśli chcesz go utrzymać ręcznie, trzeba wyłączyć odpowiednie usługi lub ustawić chattr +i /etc/resolv.conf, co jednak bywa kłopotliwe przy zmianach sieci.

macOS

macOS ma dość prostą konfigurację DNS, zarówno z GUI, jak i z linii komend.

Zmiana DNS w Preferencjach systemowych

1. Otwórz Ustawienia systemowe / Preferencje systemowe → Sieć.
2. Wybierz aktywne połączenie (Wi-Fi / Ethernet) → Szczegóły… / Zaawansowane….
3. Przejdź do zakładki DNS.
4. Usuń adresy odziedziczone z DHCP (jeśli chcesz je całkowicie zastąpić) lub zostaw jako zapas.
5. Dodaj własne serwery DNS (np. 1.1.1.1, 1.0.0.1, 9.9.9.9).
6. Zatwierdź zmiany, rozłącz i połącz ponownie.

Zmiana DNS z terminala (networksetup)

Przykład dla interfejsu Wi‑Fi:

networksetup -listallnetworkservices
sudo networksetup -setdnsservers "Wi-Fi" 1.1.1.1 1.0.0.1

Aby przywrócić DNS z DHCP:

sudo networksetup -setdnsservers "Wi-Fi" empty

Android (bez root i z root)

Na Androidzie sporo zależy od wersji systemu i nakładki producenta.

Android 9+ – prywatny DNS (DoT)

Od Androida 9 jest obsługa Private DNS (DNS-over-TLS) na poziomie całego systemu.

1. Wejdź w Ustawienia → Sieć i internet → Prywatny DNS (czasem w „Zaawansowanych”).
2. Wybierz Nazwa hosta prywatnego dostawcy DNS.
3. Wpisz nazwę hosta dostawcy DoT (np. 1dot1dot1dot1.cloudflare-dns.com, doh.dnscrypt.info, zależnie od usługodawcy).
4. Zapisz. Telefon zacznie używać szyfrowanego DNS dla wszystkich połączeń.

Android – ustawienia per Wi‑Fi

Jeżeli producent nie okroił opcji:

1. Przytrzymaj nazwę sieci Wi‑Fi → Zarządzaj siecią / Edytuj.
2. Rozwiń Ustawienia zaawansowane.
3. W sekcji Ustawienia IP wybierz Statyczne.
4. Skopiuj aktualny adres IP, maskę i bramę (żeby ich nie zepsuć).
5. W polach DNS 1 / DNS 2 wpisz wybrane serwery.

To rozwiązanie zmienia DNS tylko dla jednej sieci Wi‑Fi, ale dobrze nadaje się do testów.

Android z root – zaawansowane rozwiązania

Przy dostępie root można użyć aplikacji typu AdGuard, RethinkDNS czy DNSChanger z integracją na poziomie systemu, często z dodatkowymi filtrami reklam i malware. Wymaga to jednak większego zaufania do aplikacji i świadomego zarządzania uprawnieniami.

Konfiguracja DNS na routerze: jedno miejsce, wiele urządzeń

Dlaczego lepiej zmienić DNS na routerze

Ustawienie DNS w routerze sprawia, że:

• wszystkie urządzenia w sieci (komputery, telewizory, konsole, IoT) korzystają z tej samej konfiguracji,
• zmiana DNS wymaga jednej operacji, a nie żmudnego klikania na każdym sprzęcie,
• można dodać lokalny cache (dnsmasq, unbound) i reguły filtrowania.

Przykład z życia: po zmianie DNS na routerze na szybki publiczny + cache, streaming na telewizorze przestaje „myśleć” po naciśnięciu Play, bo aplikacja nie czeka już po kilkaset ms na odpowiedzi DNS dla wielu hostów CDN.

Typowe interfejsy routerów (ISP, SOHO, OpenWrt)

Większość routerów ma podobną strukturę menu. Szukaj sekcji typu Internet, WAN, LAN, DHCP, DNS.

Router od operatora

Bywa, że operator blokuje ręczną zmianę DNS. Jeśli opcja jest dostępna:

1. Wejdź na stronę konfiguracyjną (zwykle 192.168.0.1 lub 192.168.1.1).
2. Zaloguj się danymi z naklejki lub umowy.
3. W zakładce Internet / WAN poszukaj pól Primary DNS i Secondary DNS.
4. Wyłącz opcję „Pobierz DNS automatycznie” (o ile jest) i wpisz własne serwery.
5. Zapisz ustawienia i zrestartuj router.

Jeżeli taka możliwość nie istnieje, pozostaje:

• podpięcie własnego routera za urządzeniem operatora i przeniesienie logiki sieci do niego,
• konfiguracja DNS na poziomie systemu na każdym urządzeniu (mniej wygodne).

Typowy router SOHO (TP-Link, Asus, Netgear itp.)

Przykładowy schemat (rozmieszczenie opcji może się różnić):

1. Logujesz się na router.
2. Wchodzisz w Network → WAN.
3. W sekcji IP Configuration pozostawiasz „Dynamic IP” / PPPoE / inne zgodnie z operatorem.
4. W polach DNS wpisujesz zewnętrzne serwery (np. 1.1.1.1, 9.9.9.9).
5. Zapisujesz, restartujesz połączenie WAN.

Niektóre routery mają osobne pole na DNS dla serwera DHCP (np. w zakładce LAN). Wtedy to te adresy dostaną klienci w sieci.

OpenWrt / DD-WRT

W alternatywnych firmware wszystko jest bardziej elastyczne.

• OpenWrt (LuCI): Network → Interfaces → WAN → Edit → Advanced Settings → „Use custom DNS servers”. Wpisujesz listę serwerów, zapisujesz.
• /etc/config/network: w sekcji config interface 'wan' dodajesz np. option dns '1.1.1.1 1.0.0.1'.
• DD-WRT: Setup → Basic Setup → „Static DNS 1/2/3”.

Lokalny cache DNS na routerze (dnsmasq, unbound)

dnsmasq jako lekki cache i filtr

dnsmasq jest wbudowany w wiele routerów (SOHO, OpenWrt). Działa jako lokalny serwer DNS i DHCP, dzięki czemu skraca czas odpowiedzi dla często odwiedzanych domen.

Ogólny schemat działania:

• urządzenia w sieci pytają o DNS router,
• router, jeśli ma odpowiedź w cache, zwraca ją od razu,
• jeśli nie – pyta skonfigurowane serwery zewnętrzne, zapisuje wynik do cache i zwraca klientowi.

Podstawowa konfiguracja dnsmasq (OpenWrt)

Domyślna instalacja OpenWrt korzysta z dnsmasq. Wystarczy wskazać upstream DNS i włączyć cache:

/etc/config/dhcp

config dnsmasq
  option domainneeded '1'
  option boguspriv '1'
  option filterwin2k '0'
  option localise_queries '1'
  option rebind_protection '1'
  option local '/lan/'
  option domain 'lan'
  option expandhosts '1'
  option cachesize '1000'
  list server '1.1.1.1'
  list server '1.0.0.1'
  list server '9.9.9.9'

Po zmianach:

/etc/init.d/dnsmasq restart

Parametr cachesize określa liczbę wpisów w cache. Dla domowej sieci 500–2000 wpisów zwykle wystarczy.

Proste filtrowanie reklam i śmieci

dnsmasq potrafi zablokować wybrane domeny, zwracając np. 0.0.0.0. Mechanizm przypomina plik hosts, ale działa centralnie dla całej sieci.

/etc/dnsmasq.d/blacklist.conf

address=/doubleclick.net/0.0.0.0
address=/tracking.example.com/0.0.0.0

Po dodaniu listy i restarcie dnsmasq ruch do tych domen po prostu nie wyjdzie z sieci. Można w ten sposób wczytywać gotowe listy blokad, ale przesadnie rozbudowane zestawy czasem spowalniają start usługi.

unbound jako własny resolver rekurencyjny

unbound to „cięższa” alternatywa: pełny resolver rekurencyjny, który sam pyta serwery root, TLD i autorytatywne. Dzięki temu omija DNS operatora i nie polega na publicznych resolverach.

Typowa konfiguracja unbound (OpenWrt / Linux)

Minimalny przykład dla małej sieci domowej:

server:
  interface: 0.0.0.0
  access-control: 192.168.0.0/16 allow
  verbosity: 1
  msg-cache-size: 64m
  rrset-cache-size: 64m
  cache-min-ttl: 60
  cache-max-ttl: 86400
  prefetch: yes
  prefetch-key: yes
  hide-identity: yes
  hide-version: yes
  qname-minimisation: yes
  harden-glue: yes
  harden-dnssec-stripped: yes
  use-caps-for-id: yes

Localhost lub router staje się Twoim jedynym resolverem. Pierwsze zapytanie do rzadko odwiedzanej domeny bywa trochę wolniejsze (pełna rekurencja). Kolejne idą z cache i potrafią być szybsze niż na publicznych DNS, bo odpadają pośrednicy.

Integracja unbound z routerem

Najprościej:

• ustaw unbound, aby nasłuchiwał na porcie 53 routera,
• w dnsmasq/kolejnym DHCP skonfiguruj DNS na adres routera (zwykle już tak jest),
• opcjonalnie wyłącz własny komponent DNS w routerze, jeśli dubluje funkcję unbound.

Jeżeli router nie pozwala łatwo przechwycić portu 53, można użyć przekierowania iptables (DNAT) dla pakietów UDP/TCP 53 kierowanych na zewnętrzne serwery DNS i przekierować je do unbound.

Nowoczesne protokoły DNS: DoH, DoT i DNSSEC w praktyce domowej

Po co w ogóle szyfrować DNS

Tradycyjny DNS działa w czystym tekście. Każdy router po drodze widzi, jakie domeny odwiedzasz, a operator może je logować i modyfikować odpowiedzi. DoH i DoT szyfrują zapytania, co utrudnia podsłuch i manipulację.

• DoT (DNS-over-TLS) – DNS tunelowany w TLS na porcie 853.
• DoH (DNS-over-HTTPS) – DNS opakowany w HTTPS, zwykle port 443.
• DNSSEC – podpisy kryptograficzne rekordów DNS, chronią przed podmianą danych, ale same nie szyfrują ruchu.

DoT w domu: prostsze w routerach, trudniejsze w aplikacjach

Wiele routerów i systemów (Android, niektóre dystrybucje Linux) potrafi rozmawiać z resolverem za pomocą DoT. Z punktu widzenia sieci domowej:

• jedno miejsce konfiguracji (router lub serwer DNS w LAN),
• zapytania DNS do Internetu lecą w TLS,
• klienci w LAN nadal używają zwykłego UDP/TCP 53 do routera.

Przykładowa konfiguracja unbound z DoT jako upstream

Jeśli chcesz używać szyfrowanego połączenia do publicznego resolvera, zamiast robić pełną rekurencję lokalnie:

server:
  do-not-query-localhost: no

forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 1.1.1.1@853#cloudflare-dns.com
  forward-addr: 9.9.9.9@853#dns.quad9.net

W ten sposób unbound działa jako klient DoT. Odpowiedzi dalej cache’uje lokalnie, więc przyspieszenie jest podobne jak przy zwykłym forwardingu.

DoH w sieci domowej: kiedy ma sens

DoH jest zwykle implementowany w przeglądarkach (Firefox, Chrome, Edge) i nie wymaga zmian na routerze. Włączenie DoH sprawia, że:

• zapytania DNS z przeglądarki nie przechodzą przez lokalny resolver (router, Pi-hole itd.),
• filtrowanie DNS w sieci przestaje działać dla ruchu HTTP(S),
• zapytania wyglądają jak zwykły HTTPS do konkretnego hosta (np. mozilla.cloudflare-dns.com).

W praktyce DoH przydaje się zwłaszcza w sieciach, gdzie nie ufamy lokalnemu DNS (np. publiczne Wi‑Fi). W domu częściej wygrywa DoT na routerze + własny cache, bo zostawia kontrolę nad ruchem DNS u Ciebie.

DNSSEC: kiedy pomaga, a kiedy przeszkadza

DNSSEC pozwala zweryfikować, czy odpowiedź DNS faktycznie pochodzi z autorytatywnego serwera, a nie z podszywającego się cache po drodze. Działa na poziomie resolvera (np. unbound) i wymaga:

• obsługi DNSSEC po stronie resolvera,
• poprawnej konfiguracji łańcucha podpisów w domenie,
• aktualnych kluczy root na Twoim serwerze DNS.

Konfiguracja DNSSEC w unbound zwykle sprowadza się do:

server:
  auto-trust-anchor-file: "/var/lib/unbound/root.key"
  val-permissive-mode: no
  harden-dnssec-stripped: yes

Problem pojawia się, gdy jakaś domena ma źle skonfigurowane DNSSEC – wtedy resolver odrzuca odpowiedź, a strona „nie działa”. Z punktu widzenia użytkownika wygląda to jak przypadkowa awaria sieci. W takich sytuacjach trzeba:

1. sprawdzić logi unbound/dnsmasq,
2. przekonać się, czy to nie błąd u usługodawcy,
3. ewentualnie tymczasowo przełączyć się na resolver, który nie waliduje DNSSEC.

Podstawy TCP/IP, które mają wpływ na szybkość połączeń

Nie tylko megabity: gdzie „ucieka” czas

Większość problemów z „muli” i „laguje” przy dobrej przepustowości wynika z:

• wysokiego RTT (pingu),
• niestabilnych lub przeciążonych łączy pośrednich,
• złych parametrów TCP (małe okno, brak skalowania, brak SACK),
• zbyt małego lub zbyt dużego MTU/MSS, powodującego fragmentację lub dropy.

TCP reaguje na straty i opóźnienia, zwalniając. Dlatego poprawna konfiguracja warstwy IP i TCP ma przełożenie na szybkość ładowania stron, streamingu czy gier, nawet bez zmiany pakietu u operatora.

3‑way handshake i opóźnienia startu połączenia

Przy każdym nowym połączeniu TCP klient i serwer wykonują trzyetapowe uzgadnianie (SYN → SYN/ACK → ACK). To oznacza:

• minimum jedno RTT, zanim w ogóle popłyną dane użytkowe,
• każde dodatkowe opóźnienie po drodze (NAT, firewall, VPN) powiększa ten czas.

Dlatego:

• router przeciążony filtrowaniem lub logowaniem może zwiększać RTT,
• niektóre „inteligentne” funkcje (np. DPI w tańszych routerach) bardziej szkodzą niż pomagają.

Slow start, okno TCP i skalowanie okna

TCP zaczyna od małego okna i stopniowo je powiększa. Im większe okno, tym więcej danych może być „w locie” bez potwierdzenia. Dla łączy o większym opóźnieniu (np. zagraniczne serwery) to kluczowe.

Wydajność maksymalna ≈ okno / RTT. Przykład:

• RTT do serwera: 50 ms,
• okno skuteczne 64 kB.

Przepustowość z takiego połączenia będzie niższa niż potencjał łącza łącza 300 Mb/s, bo TCP nie nadąża z „napełnieniem” rury.

Sprawdzenie parametrów TCP w systemie

Na Linuksie parametry TCP widać i zmienia się przez /proc/sys/net/ipv4 i sysctl.

sysctl net.ipv4.tcp_window_scaling
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem
sysctl net.ipv4.tcp_sack

Podstawowe ustawienia, które zwykle warto mieć włączone:

• tcp_window_scaling=1 – skalowanie okna, umożliwia większe okna TCP,
• tcp_sack=1 – Selective Acknowledgements, lepsze zachowanie przy pojedynczych stratach.

Przykładowa sensowna konfiguracja pod typowe łącza domowe:

sysctl -w net.ipv4.tcp_window_scaling=1
sysctl -w net.ipv4.tcp_sack=1
sysctl -w net.ipv4.tcp_rmem="4096 87380 6291456"
sysctl -w net.ipv4.tcp_wmem="4096 65536 6291456"

Aby utrwalić, dodaj do /etc/sysctl.conf.

Algorytmy kontroli przeciążenia TCP

Nowoczesne systemy oferują różne algorytmy kontroli przeciążenia (congestion control). Od nich zależy, jak agresywnie TCP zwiększa prędkość, jak reaguje na straty i zmienny RTT.

Na linuksowych routerach i serwerach warto sprawdzić:

sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control

Typowe wartości:

• cubic – domyślny w wielu dystrybucjach, dobry ogólny wybór,
• bbr – nastawiony na maksymalizację throughput przy wysokim RTT, świetny dla serwerów www,
• reno – starszy, raczej do celów testowych lub kompatybilności.

Zmiana na bbr może przyspieszyć wysyłkę danych z serwera do klientów, zwłaszcza gdy łącze ma większe opóźnienia. Na typowym domowym desktopie różnice będą mniejsze, ale na domowym serwerze (np. NAS z dostępem z Internetu) – już odczuwalne.

MTU i MSS: jak ustawić, żeby nie tracić pakietów po drodze

Co to jest MTU i dlaczego ma znaczenie

MTU (Maximum Transmission Unit) to maksymalny rozmiar jednego pakietu L2/L3, jaki może przejść przez dane łącze bez fragmentacji. Standardowe wartości:

• Ethernet: 1500 bajtów,
• PPPoE: zwykle 1492 (narzut PPPoE),
• VPN (OpenVPN, IPsec, WireGuard): efektywne MTU jest niższe z powodu dodatkowego nagłówka.

Jeśli MTU jest ustawione zbyt wysoko względem faktycznych możliwości trasy, pakiety są fragmentowane lub wręcz wyrzucane przez urządzenia po drodze. To objawia się m.in. ładowaniem części stron, problemami z niektórymi aplikacjami, time‑outami przy większych transferach.

MSS – rozmiar segmentu TCP

MSS (Maximum Segment Size) to maksymalna ilość danych w jednym segmencie TCP (bez nagłówków IP/TCP). Jest powiązane z MTU poprzez:

MSS ≈ MTU - 40 (20 bajtów nagłówka IP + 20 bajtów nagłówka TCP, bez opcji).

W praktyce obniżenie MSS na routerze pozwala uniknąć fragmentacji TCP nawet wtedy, gdy po drodze jest mniejsze MTU, a ICMP „Fragmentation Needed” jest blokowane.

Jak dobrać właściwe MTU na łączu

Najczęściej zadawane pytania (FAQ)

Dlaczego strony ładują się wolno, skoro speedtest pokazuje wysoki transfer?

Speedtest mierzy głównie maksymalną przepustowość podczas ciągłego transferu danych. Nie pokazuje, ile czasu zajmuje start połączenia: zapytanie do DNS, zestawienie TCP, negocjacja HTTPS i dopiero potem właściwy transfer. Jeśli któryś z tych etapów jest wolny, strony będą „zastanawiać się” przed rozpoczęciem ładowania, mimo świetnych wyników testu.

Typowy objaw to sytuacja, gdy pasek adresu „myśli” kilka sekund, a dopiero potem nagle pojawia się cała treść. Często winne są wolne lub niestabilne serwery DNS, zły MTU/MSS albo źle dobrane bufory TCP – czyli konfiguracja, a nie samo łącze od operatora.

Czy zmiana DNS może przyspieszyć internet bez zmiany operatora?

Tak. Szybszy, stabilny DNS skraca czas potrzebny na przetłumaczenie nazw domen na adresy IP. To pierwszy krok przed każdym połączeniem HTTP/HTTPS, więc wpływa bezpośrednio na moment startu ładowania strony. Różnice rzędu kilkuset milisekund na zapytanie DNS kumulują się przy stronach korzystających z wielu domen.

Prosty test w domu: ustaw na routerze lub komputerze inne, znane serwery (np. Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) i porównaj, jak szybko rusza ładowanie tych samych stron. Jeśli „szare okno” w przeglądarce znika szybciej, trafiłeś na lepszy DNS.

Jak sprawdzić, czy problemem jest DNS czy konfiguracja TCP/IP?

Najprostsza ścieżka diagnostyczna:

• sprawdź ping do kilku popularnych serwerów (np. 1.1.1.1, 8.8.8.8) – wysokie, niestabilne wartości wskazują na problem z trasą/łączeniem, a nie z DNS;
• użyj narzędzi typu nslookup lub dig i zmierz czas odpowiedzi DNS dla kilku domen – jeśli trwa to setki ms, DNS jest podejrzany;
• zrób speedtest i obserwuj wykres – „ząbkowane” linie lub nagłe spadki w trakcie testu sugerują problem z retransmisjami TCP (utrata pakietów, zły MTU).

Dobry scenariusz: niski ping, szybki speedtest, ale wolny start stron – wtedy najczęściej pomaga zmiana DNS i włączenie lokalnego cache. Problemy z ciągłością transferu lub zrywaniem VPN częściej wynikają z parametrów TCP/IP, MTU i jakości łącza po drodze.

Co to jest TTFB i jak DNS wpływa na czas „pierwszego bajtu”?

TTFB (Time To First Byte) to czas od wysłania żądania HTTP(S) do otrzymania pierwszego bajtu odpowiedzi z serwera. W praktyce to chwila od wciśnięcia Entera do momentu, gdy przeglądarka zaczyna faktycznie pobierać dane. W TTFB zawiera się czas DNS, handshake TCP, negocjacja TLS oraz czas przetwarzania po stronie serwera.

Jeśli sam DNS zabiera kilkaset milisekund, sztucznie podbija cały TTFB, nawet gdy serwer WWW jest szybki. Po zmianie na wydajniejszy DNS czas tego etapu potrafi spaść do kilkunastu–kilkudziesięciu ms, co przy wielu domenach na stronie daje zauważalne przyspieszenie startu ładowania.

Czy lepiej używać DNS operatora, publicznych DNS czy własnego resolvera?

Nie ma jednej odpowiedzi dla wszystkich, ale można przyjąć prostą logikę:

• DNS operatora – często ma najkrótszą trasę, ale bywa przeciążony, filtrowany i niestabilny;
• publiczne DNS (Google, Cloudflare, Quad9) – zwykle stabilniejsze, z dodatkowymi funkcjami (DoH/DoT, filtracja złośliwych domen), ale ich opóźnienie zależy od tego, jak Twój ISP dochodzi do tych serwerów;
• własny resolver z cache (np. dnsmasq, unbound) – po pierwszym zapytaniu trzyma wynik „blisko” użytkownika i skraca kolejne odwołania do kilku ms.

W praktyce w sieci domowej dobrze sprawdza się konfiguracja: szybki zewnętrzny DNS (operatora lub publiczny) + lokalny cache DNS na routerze. Dzięki temu łączysz niskie opóźnienie z minimalną liczbą wyjść na zewnątrz przy powtarzających się zapytaniach.

Jakie objawy wskazują na złą konfigurację MTU/MSS lub TCP przy dobrym łączu?

Błędne MTU/MSS i źle dobrane bufory TCP zwykle nie „psują” speedtestu od razu, ale wychodzą przy normalnym korzystaniu z sieci. Typowe objawy to:

• niektóre strony ładują się bardzo wolno lub „wiszą” na etapie nawiązywania połączenia, inne działają normalnie;
• VPN rozłącza się lub nie otwiera części serwisów, mimo że zwykłe przeglądanie bez VPN działa;
• pobieranie plików ma skokowy przebieg: rusza szybko, spada niemal do zera, znów przyspiesza.

Takie zachowanie często wynika z fragmentacji pakietów po drodze lub błędnej interpretacji strat przez TCP jako przeciążenia. Korekta MTU/MSS na routerze lub kliencie oraz dopasowanie parametrów TCP do jakości łącza potrafi ustabilizować transfer bez zmiany operatora.

Czym różni się opóźnienie od jittera i utraty pakietów w odczuwalnej „szybkości” internetu?

Opóźnienie (latency) to czas, w jakim pakiet wraca z odpowiedzią. Wpływa na „czas reakcji” – jak szybko po kliknięciu zacznie się dziać cokolwiek: start ładowania strony, reakcja w grze, rozpoczęcie pobierania. Wysoka, ale stabilna latencja daje „muła”, ale przewidywalnego.

Jitter to zmienność opóźnienia. Dla gier, VoIP i wideokonferencji jest często większym problemem niż same ms pingu, bo powoduje zacinanie, teleportowanie postaci i „chrupiący” dźwięk. Utrata pakietów dokłada do tego retransmisje w TCP, które obniżają realną przepustowość. Dobra konfiguracja DNS i TCP/IP nie usunie fizycznych problemów linii, ale pomaga lepiej wykorzystać istniejące łącze, ograniczając dodatkowe opóźnienia po stronie urządzeń i systemu.