Dobre ustawienia dns potrafią rozwiązać problemy, które z zewnątrz wyglądają jak awaria internetu: strony otwierają się wolno, niektóre domeny nie odpowiadają, a VPN miesza ruch z siecią domową. W tym tekście pokazuję, czym naprawdę są te ustawienia, gdzie najlepiej je zmienić, jak zrobić to na Linuxie i jak sprawdzić, czy konfiguracja faktycznie działa. Skupiam się na praktyce, bo w sieciach komputerowych właśnie szczegóły decydują o tym, czy wszystko działa płynnie, czy tylko „na oko”.
Najważniejsze rzeczy o DNS, zanim zmienisz cokolwiek w konfiguracji
- DNS tłumaczy nazwy domen na adresy IP, więc odpowiada za to, czy w ogóle trafisz do właściwej usługi.
- Najpierw decyduj, gdzie zmienić resolver: na urządzeniu, na routerze albo w profilu VPN.
- Na Linuxie najczęściej robisz to przez NetworkManager lub systemd-resolved, a nie przez ręczną edycję `/etc/resolv.conf`.
- Po zmianie zawsze sprawdź aktywny serwer poleceniem `resolvectl status` albo `resolvectl query`.
- Jeśli problem dotyczy tylko jednej sieci lub domeny firmowej, zwykły globalny DNS może nie wystarczyć.
Czym są serwery DNS i kiedy ich ustawienia naprawdę mają znaczenie
DNS to warstwa, która tłumaczy nazwę domeny na adres IP. Przeglądarka nie „zna” adresu strony, dopóki nie zapyta resolvera, a ten nie wskaże właściwego hosta. Jeśli resolver działa wolno, jest przeciążony albo źle skonfigurowany, użytkownik widzi opóźnienia, błędy ładowania albo losowe problemy z częścią serwisów, mimo że samo łącze nadal działa.
W praktyce DNS zmieniam wtedy, gdy chcę ograniczyć wpływ wadliwego resolvera operatora, poprawić spójność działania przy VPN albo ustawić bardziej przewidywalne zachowanie dla całej sieci. Trzeba jednak zachować realizm: DNS przyspiesza tylko etap rozwiązywania nazw. Nie naprawi słabego Wi-Fi, złej trasy routingu, problemów z MTU ani niestabilnego łącza.
To też dobry moment, żeby odróżnić „działa internet” od „działa rozwiązywanie nazw”. Serwis może odpowiadać pod adresem IP, a mimo to być niedostępny po nazwie domenowej. W takich sytuacjach DNS jest pierwszym miejscem, które sprawdzam, bo właśnie tam zwykle kryje się problem. Gdy już wiesz, co zmieniasz, pozostaje ważniejsze pytanie: gdzie to zrobić, żeby efekt objął dokładnie ten ruch, który ma objąć.
Gdzie najlepiej zmienić DNS w domu i w firmie
Ja zwykle zaczynam od miejsca, w którym problem faktycznie się ujawnia. To ważniejsze niż sam wybór konkretnego adresu serwera, bo zła warstwa konfiguracji daje tylko pozorne wrażenie poprawy. W praktyce masz trzy sensowne poziomy: pojedyncze urządzenie, router albo profil VPN.
| Miejsce zmiany | Co obejmuje | Kiedy ma sens | Ograniczenia |
|---|---|---|---|
| Urządzenie | Jedną maszynę, laptop, serwer lub telefon | Problem występuje tylko na jednym sprzęcie albo chcesz zrobić szybki test | Inne urządzenia nadal korzystają ze starej konfiguracji |
| Router | Całą sieć domową lub biurową | Wszystkie urządzenia mają te same objawy albo chcesz ujednolicić DNS w domu | Trzeba odświeżyć dzierżawy DHCP, a część klientów długo trzyma cache |
| VPN lub profil sieciowy | Ruch dla konkretnego tunelu, domeny lub zakresu adresów | Sieć firmowa, split tunneling, zasoby wewnętrzne | Łatwo o konflikt z innym profilem i wyciek DNS poza tunel |
Jeśli objaw dotyczy tylko mojego laptopa, zmieniam DNS lokalnie. Jeśli kilka urządzeń w domu ma ten sam problem, idę w stronę routera. A gdy wchodzi w grę praca zdalna albo zasoby firmowe, lepiej nie mieszać wszystkiego w jeden globalny resolver, tylko ustawić DNS bliżej konkretnego tunelu. To prowadzi już prosto do praktyki na Linuxie.
Jak zmienić DNS w Linuxie bez walki z `/etc/resolv.conf`
Na laptopach i desktopach z NetworkManagerem to najwygodniejsza droga. Najpierw sprawdzam aktywne połączenie, potem ustawiam własne serwery DNS i wyłączam pobieranie DNS z DHCP, bo inaczej automatyczna konfiguracja potrafi nadpisać mój wybór. Jeśli zmieniasz tylko jedną sieć Wi-Fi, dotyczy to konkretnego profilu, nie całego systemu.
Przez NetworkManager
nmcli con show --active
nmcli con mod "NAZWA_POŁĄCZENIA" ipv4.ignore-auto-dns yes ipv4.dns "1.1.1.1 1.0.0.1"
nmcli con mod "NAZWA_POŁĄCZENIA" ipv6.ignore-auto-dns yes ipv6.dns "2606:4700:4700::1111 2606:4700:4700::1001"
nmcli con down "NAZWA_POŁĄCZENIA" && nmcli con up "NAZWA_POŁĄCZENIA"W praktyce to działa najlepiej wtedy, gdy chcesz mieć oddzielne konfiguracje dla domu, biura i VPN. Ja lubię tę metodę, bo jest powtarzalna, a po restarcie nie znika. Jeśli nie korzystasz z IPv6, możesz pominąć drugi blok, ale nie zostawiaj połowy konfiguracji przypadkiem. W sieciach mieszanych niedopatrzenie przy IPv6 bywa źródłem bardziej podstępnych problemów niż sam IPv4.
Przeczytaj również: Jak sprawdzić IP w Linuxie - lokalny i publiczny adres
Przez systemd-resolved
Na systemach, gdzie resolverem zarządza systemd-resolved, nie edytuję `/etc/resolv.conf` na ślepo. Często to tylko plik sterowany przez usługę, a ręczna zmiana zniknie po restarcie albo odświeżeniu połączenia. Bezpieczniej użyć własnego pliku konfiguracyjnego dla resolvera i zrestartować usługę.
[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=9.9.9.9 149.112.112.112sudo systemctl restart systemd-resolvedPo stronie systemd-resolved ważne jest jeszcze jedno: lokalny stub DNS na adresie `127.0.0.53` jest normalny. To nie jest zewnętrzny serwer, tylko lokalny pośrednik, który przekazuje zapytania dalej. Jeśli widzisz taki adres w konfiguracji, nie oznacza to automatycznie błędu.
Na serwerach bez GUI, ale z NetworkManagerem, można też pracować na profilu po stronie pliku konfiguracyjnego, a potem wykonać `nmcli con reload`. Traktuję to jednak jako plan B. Gdy mam wybór, wolę zmieniać profil przez `nmcli`, bo łatwiej wtedy utrzymać spójność i szybciej odtworzyć ustawienia po awarii.
Po takiej zmianie nie zakładam, że wszystko już działa. Najpierw to sprawdzam, najlepiej na poziomie konkretnego interfejsu i konkretnej domeny.
Jak sprawdzić, czy nowy DNS rzeczywiście działa
Po zmianie nie zgaduję, tylko weryfikuję, skąd system bierze odpowiedzi. `resolvectl status` pokazuje aktywne serwery per interfejs, a `resolvectl query example.org` pozwala szybko przetestować samo rozwiązywanie nazw. Jeśli używasz systemd-resolved, możesz też wyczyścić cache, żeby nie patrzeć na stary wynik zapisany wcześniej.
resolvectl status
resolvectl query example.org
resolvectl flush-cachesWynik `status` czytam zawsze uważnie. Interesuje mnie przede wszystkim to, który interfejs ma przypisany DNS, czy nie pojawił się stary serwer z DHCP oraz czy ruch dla domen firmowych idzie przez właściwy link. Jeśli połączenie VPN działa, ale zapytania nadal wychodzą przez sieć domową, problem jest zwykle w routingu DNS, a nie w samym adresie resolvera.
Gdy test pokazuje stare odpowiedzi, a wszystko wygląda dobrze na papierze, winny bywa cache albo zbyt powolne odświeżenie dzierżawy DHCP. Wtedy odłączam i ponownie podłączam interfejs, a w razie potrzeby robię pełne przeładowanie profilu. Ta prosta czynność często oszczędza więcej czasu niż dłubanie w kolejnych plikach konfiguracyjnych.
Jeśli wynik wygląda dziwnie, najczęściej nie chodzi już o sam DNS, tylko o jeden z kilku klasycznych błędów konfiguracji.
Najczęstsze błędy przy zmianie DNS
- Edytowanie złego pliku. Na systemach z NetworkManagerem albo systemd-resolved ręczna zmiana `/etc/resolv.conf` bywa nietrwała, bo usługę ktoś nadpisuje przy kolejnym odświeżeniu połączenia.
- Zmiana tylko IPv4. Jeśli IPv6 nadal wskazuje stary resolver, część ruchu może iść inną drogą, niż zakładasz.
- Pozostawienie automatycznego DNS z DHCP. Bez `ignore-auto-dns yes` ręcznie wpisane serwery mogą zostać wypchnięte przez konfigurację z routera lub operatora.
- Brak odnowienia dzierżawy po zmianie na routerze. Klient może trzymać stare ustawienia, dopóki nie rozłączy się z siecią albo nie odświeży DHCP.
- Oczekiwanie, że DNS naprawi routing. Jeśli problemem jest MTU, firewall, captive portal albo zła trasa, sama zmiana resolvera niewiele da.
- Ignorowanie cache przeglądarki i systemu. Stary wynik potrafi utrzymywać się dłużej, niż się wydaje, więc test trzeba robić po odświeżeniu połączenia.
Największy błąd, jaki widzę, to mieszanie poziomów. Ktoś zmienia DNS na laptopie, a potem oczekuje poprawy na całej sieci. Albo odwrotnie: ustawia resolver w routerze, ale testuje tylko jedno urządzenie, które i tak ma własny profil VPN. Gdy podejdziesz do tego warstwowo, diagnostyka jest dużo prostsza. A skoro temat dotyczy też bezpieczeństwa, warto zamknąć go kilkoma dodatkowymi ustawieniami, które naprawdę robią różnicę.
Co warto ustawić obok samego DNS, jeśli zależy ci na bezpieczeństwie i porządku
Jeśli DNS ma być nie tylko szybki, ale też rozsądnie poukładany, patrzę na trzy rzeczy: szyfrowanie, weryfikację i routing per interfejs. DNSSEC pomaga wykrywać fałszywe odpowiedzi, ale nie szyfruje ruchu. DoT i DoH szyfrują zapytania do resolvera, ale ich obsługa zależy od dystrybucji, wersji NetworkManagera i tego, czy twój stos sieciowy faktycznie wspiera taki backend. Nie zakładam tego z góry.
W środowisku firmowym bardzo przydają się domeny routujące. Domeny zaczynające się od `~`, na przykład `~firma.local`, nie służą do dopisywania nazwy hosta, tylko do wskazania, przez który interfejs ma iść zapytanie. To ważne przy VPN i split tunnelingu, bo pozwala utrzymać ruch do zasobów wewnętrznych poza publicznym DNS-em.
Zostawiam też sensowną hierarchię priorytetów. Jednego resolvera traktuję jako główny, a fallback jako zapas na wypadek awarii. To prostsze niż układanie kilku równorzędnych źródeł, które potem konkurują ze sobą i dają nieprzewidywalne wyniki. W `resolvectl status` czy NetworkManagerze od razu widać, czy konfiguracja jest uporządkowana, czy już zaczyna się chaos.
Gdybym miał zostawić jedną praktyczną regułę, brzmiałaby tak: zmieniaj DNS najbliżej miejsca, w którym ma działać, i od razu go weryfikuj. Na Linuxie najczęściej najczystszy efekt daje NetworkManager albo systemd-resolved, a ręczne grzebanie w `resolv.conf` zostawiam tylko wtedy, gdy dokładnie wiem, kto ten plik nadpisuje.
Jeśli po poprawnej konfiguracji nadal widzisz błędy, problem zwykle leży już nie w DNS, tylko w trasowaniu, filtracji ruchu, VPN albo wygasłym cache. To dobry moment, żeby spojrzeć szerzej na całą ścieżkę pakietu, a nie tylko na sam resolver.
