Strona główna
» Jak
»
Niepowodzenia wyszukiwania DNS w systemie Debian 12: naprawa błędu systemd-resolved
Niepowodzenia wyszukiwania DNS w systemie Debian 12: naprawa błędu systemd-resolved
Jeśli w systemie Debian 12 wyświetla się komunikat „Tymczasowy błąd rozpoznawania nazw”, sprawdź usługę resolvera, /etc/resolv.confłącze oraz serwery DNS oznaczone literą resolvectl— w tej kolejności. Ponowne uruchomienie usługi pomaga tylko po jej zatrzymaniu; zerwane łącze lub niedostępny serwer nadrzędny wymagają innego rozwiązania.
Niniejsze instrukcje dotyczą systemów Debian 12 (Bookworm) skonfigurowanych do korzystania z usługi DNS systemd-resolved. Debian wydzielił ten resolver do osobnego pakietu i nie uczynił go domyślnym, jak wyjaśniono w informacjach o wydaniu Debiana 12. Jeśli Twoja instalacja korzysta z innego menedżera DNS, zachowaj kontrolę nad nim, zamiast narzucać mu te ustawienia.
1. Zidentyfikuj, gdzie rozpoznawanie nazw zawodzi
Zacznij od trasy sieciowej i wyszukania nazwy hosta. Uruchom polecenia lokalnie lub w terminalu, który pozostanie otwarty w przypadku zmian w sieci:
ip -br address
ip route
ping -c 2 1.1.1.1
resolvectl status
resolvectl query debian.org
getent ahosts debian.org
Domyślna trasa i działające połączenie numeryczno-IP sugerują, że komputer może połączyć się z siecią bez DNS. Nieudany ping sam w sobie nie dowodzi awarii trasy: sieci mogą blokować odpowiedzi echa ICMP. Jeśli interfejsowi brakuje adresu lub trasy, należy najpierw naprawić połączenie sieciowe.
resolvectl statusPokazuje serwery DNS i domeny przypisane globalnie lub do poszczególnych interfejsów. resolvectl queryTestuje resolver systemd; getent ahoststestuje ścieżkę wyszukiwania nazw hostów powszechnie używaną przez aplikacje Linux. Rozróżnienie pomaga w wyizolowaniu błędu.
Obserwacja
Następne sprawdzenie
Brak adresu lub domyślnej trasy
Przed uruchomieniem usługi DNS należy naprawić interfejs, bramę lub konfigurację DHCP.
resolvectlnie można połączyć się z usługą
Sprawdź, czy systemd-resolvedjest zainstalowany i uruchomiony.
Oba wyszukiwania kończą się niepowodzeniem, a trasa jest aktywna
Sprawdź adresy DNS, routing DNS i dostęp do zapory sieciowej.
Widok terminala grupuje domyślną trasę sieciową, przypisanie serwera DNS i wyszukiwanie nazwy hosta na poziomie aplikacji na potrzeby wstępnej diagnostyki.
2. Upewnij się, że systemd-resolved jest zainstalowany i aktywny
W systemie Debian 12 obecność systemd nie gwarantuje zainstalowania osobnego pakietu resolvera. Przed zmianą jakichkolwiek plików DNS sprawdź pakiet i jednostkę:
dpkg-query -W -f='${Status}\n' systemd-resolved
systemctl status systemd-resolved --no-pager
Jeżeli pakiet jest zainstalowany, ale usługa jest nieaktywna, uruchom ją i włącz na potrzeby przyszłych uruchomień:
Końcowe polecenie powinno zgłosić błąd active. Jeśli urządzenie ulegnie awarii, sprawdź jego rzeczywiste komunikaty o błędach, zamiast wielokrotnie je restartować:
Jeśli pakiet jest nieobecny, zainstaluj go sudo apt install systemd-resolveddopiero po uzyskaniu dostępu do repozytorium pakietów. Instalacja pakietu zmienia kontrolę nad programem /etc/resolv.conf, dlatego najpierw sprawdź konfigurację NetworkManager, VPN lub statycznego DNS. Debian dokumentuje tę zmianę pakietu w uwagach dotyczących aktualizacji Bookworm .
Wyświetlacz stanu usługi pokazuje, gdzie szukać załadowanej jednostki, stanu aktywnego i komunikatów startowych.
3. Napraw łącze do resolvera tylko wtedy, gdy jest nieprawidłowe
Standardowy systemd-resolvedstub nasłuchuje w 127.0.0.53. Zalecany plik zgodności to /run/systemd/resolve/stub-resolv.conf, który można połączyć z /etc/resolv.conf. Najpierw sprawdź swój aktualny tryb:
ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
resolvectl status
Link do /run/systemd/resolve/resolv.confjest również obsługiwanym trybem, ale programy korzystające z niego kontaktują się bezpośrednio z nadrzędnym serwerem DNS, a nie z lokalnym szczątkiem. Nie należy nazywać tego linku uszkodzonym tylko dlatego, że się różni. Obsługiwane tryby są wyjaśnione w podręczniku serwisowym systemu Debian systemd-resolved .
Jeśli celowo używasz lokalnego szczątkowego pliku, usługa działa, nasłuchiwacz szczątkowego pliku jest włączony, a istniejący plik /etc/resolv.confjest nieobecny, zawieszony lub wskazuje na przestarzały resolver, przywróć zalecane łącze. Najpierw utwórz kopię zapasową istniejącego pliku lub łącza; pomiń kopiowanie, jeśli plik nie istnieje:
Nie uruchamiaj tego zamiennika na hoście, na którym inna usługa celowo zarządza /etc/resolv.conf. Wpis lokalny nameserver 127.0.0.53wymaga również działającego nasłuchiwacza szczątkowego; samo wpisanie tego adresu nie powoduje utworzenia usługi DNS. Na komputerze zdalnym zachowaj drugą metodę dostępu przed edycją ustawień resolvera.
Sprawdzenie dowiązania symbolicznego pokazuje oczekiwany cel, gdy Debian jest celowo skonfigurowany do używania lokalnego szczątkowego pliku rozdzielonego przez systemd.
4. Napraw nieobecny lub niedostępny serwer DNS
Jeśli resolvectl statusnie ma odpowiedniego serwera DNS upstream lub skonfigurowany serwer jest niedostępny, popraw źródło tego przypisania. Ustawienia dynamicznego DNS mogą pochodzić z DHCP, NetworkManager, systemd-networkd lub VPN. Sprawdź, który interfejs obsługuje trasę domyślną i który serwer DNS należy do tego interfejsu.
Aby przeprowadzić krótki test diagnostyczny w sieci obsługującej publiczny DNS, przypisz znane publiczne resolvery do tego interfejsu. Zastąp je ens33rzeczywistym interfejsem z ip -br address:
sudo resolvectl dns ens33 1.1.1.1 1.0.0.1
resolvectl query debian.org
Te dwa adresy są udokumentowane przez Cloudflare jako publiczne adresy resolvera DNS . resolvectl dnsZmiana dotyczy konfiguracji środowiska uruchomieniowego; menedżer sieci może ją zastąpić po ponownym nawiązaniu połączenia. Jeśli wyszukiwanie teraz działa, należy naprawić stałe źródło DNS zamiast polegać na tym tymczasowym poleceniu.
Za pomocą NetworkManager sprawdź aktywne połączenie nmcli connection show --activei dostosuj jego ustawienia DNS lub zachowanie DHCP. Za pomocą systemd-networkd wpisz odpowiednie DNS=ustawienia do odpowiedniego .networkpliku i przeładuj lub skonfiguruj sieć w bezpiecznym momencie. Zapoznaj się z podręcznikiem Debian systemd.network oraz podręcznikiem konfiguracji Debian NetworkManager . Ponowne połączenie z zarządzanym interfejsem może przerwać sesję SSH.
Preferuj serwery DNS organizacji lub sieci VPN dla nazw wewnętrznych. Nie można zakładać, że publiczne resolvery będą odpowiadać strefom prywatnym; wymuszanie wszystkich zapytań do nich może spowodować przerwanie działania podzielonego DNS lub ujawnienie wewnętrznych nazw hostów. Globalne DNS=wpisy w pliku resolved.confmogą działać równolegle z DNS dla łącza per-link, zamiast automatycznie go zastępować; patrz podręcznik Bookworm solved.conf .
5. Wyczyść pamięć podręczną i sprawdź, czy obie ścieżki wyszukiwania działają
Po poprawieniu usługi, łącza resolvera lub konfiguracji nadrzędnej wyczyść buforowane odpowiedzi i przetestuj ponownie:
Naprawa jest skuteczna, gdy resolvectl queryzwracane są adresy, getent ahostszwracane są rekordy adresów, a docelowe serwery DNS pozostają widoczne po ponownym połączeniu z siecią. Te dwa polecenia testują różne interfejsy, więc nie należy traktować sukcesu w jednym z nich jako dowodu na naprawienie wszystkich aplikacji. Podręcznik polecenia resolvectl w Debianie opisuje zapytania, status i opróżnianie pamięci podręcznej.
Końcowy widok terminala pokazuje dwa sprawdzenia, które powinny zwrócić rekordy adresów po naprawieniu konfiguracji DNS.
Jeśli resolvectl querypróba się powiedzie, ale getentnadal nie powiedzie, sprawdź grep "^hosts:" /etc/nsswitch.confi potwierdź, czy na ścieżce wyszukiwania znajduje się odpowiedni dnslub zainstalowany resolvemoduł NSS. Jeśli oba nadal się nie udają, sprawdź dziennik resolvera i wszelkie ograniczenia zapory sieciowej dotyczące ruchu DNS, a następnie przetestuj, używając rzeczywistego adresu DNS firmy, routera lub dostawcy. Samo pomyślne wyszukiwanie nie wystarczy: powtórz sprawdzanie po ponownym połączeniu i ponownym uruchomieniu, aby zweryfikować trwałe rozwiązanie.