Napraw „Tymczasową awarię rozwiązywania DNS” w Debianie 12 za pomocą systemd-resolved

Błąd Temporary failure in name resolutionoznacza, że ​​aplikacja nie mogła przekształcić nazwy hosta, np. deb.debian.orgw adres IP. W systemie Debian 12 (Bookworm) nie oznacza to automatycznie, że systemd-resolvedproblem jest rozwiązany. System Debian 12 nie jest instalowany systemd-resolveddomyślnie, a DNS może być zarządzany bezpośrednio przez NetworkManager, ifupdown, narzędzia DHCP lub inny resolver. Jeśli celowo włączono [brakuje informacji o błędzie] systemd-resolved, najszybszym rozwiązaniem jest zidentyfikowanie warstwy, która uległa awarii, przed zmianą konfiguracji.

Ten praktyczny podręcznik koncentruje się na systemach, które używają lub mają używać systemu systemd-resolved. Dokumentacja pakietu Bookworm Debiana zawiera informacje o instalowaniu systemd-resolvedprzełączników /etc/resolv.confz zarządzaniem systemd-resolved. Usługa ta zapewnia lokalny szczątkowy serwer DNS 127.0.0.53i akceptuje informacje DNS z konfiguracji globalnej, konfiguracji sieci dla poszczególnych łączy, DHCP, resolvectl. oraz usług zarządzania siecią. Więcej informacji można znaleźć na stronie pakietu Debian systemd-resolved oraz w podręczniku Debian systemd-resolved .

Szybka lista kontrolna diagnozy

1. Sprawdź, czy problem dotyczy DNS, a nie ogólnej łączności

Zacznij od przetestowania nazwy hosta, a następnie adresu IP:

getent ahosts debian.org
ping -c 3 debian.org
ping -c 3 1.1.1.1

Jeśli wyszukiwanie nazwy hosta zakończy się niepowodzeniem, a bezpośredni test IP zakończy się powodzeniem, prawdopodobną domeną błędu jest DNS. Jeśli oba testy zawiodą, najpierw sprawdź interfejs, trasę, bramę, sieć VLAN, powiązanie Wi-Fi, zaporę sieciową lub sieć nadrzędną. Zmiana DNS nie naprawi brakującej trasy domyślnej.

Aby uzyskać bardziej deterministyczne sprawdzenie routingu, uruchom także:

ip address
ip route

Zwykle powinieneś mieć adres oczekiwanego interfejsu i trasę domyślną. Dokładna nazwa interfejsu może brzmieć enp1s0, ens160, eth0lub coś innego.

2. Sprawdź, czy systemd-resolved jest faktycznie używany

Nie zakładaj, że jest on obecny tylko dlatego, że komputer korzysta z systemd. Sprawdź zarówno pakiet, jak i usługę:

dpkg -s systemd-resolved 2>/dev/null | grep '^Status'
systemctl status systemd-resolved --no-pager
resolvectl status

Jeśli pakiet jest nieobecny, a na komputerze działa inna, działająca konfiguracja zarządzania DNS, instalacja systemd-resolvednie jest automatycznie właściwym rozwiązaniem. Jeśli system powinien z niego korzystać, a usługa jest zainstalowana, ale zatrzymana, włącz ją i uruchom:

sudo systemctl enable --now systemd-resolved

Jeśli to polecenie nie zadziała, przed ponownym uruchomieniem usługi sprawdź dzienniki:

journalctl -u systemd-resolved -b --no-pager

3. Przed zastąpieniem pliku /etc/resolv.conf sprawdź jego poprawność

Najczęstszym błędem konfiguracyjnym jest traktowanie /etc/resolv.confpliku jako izolowanego. Dzięki temu systemd-resolvedplik może działać w kilku obsługiwanych trybach. Zalecany przez upstream tryb szczątkowy łączy się /etc/resolv.confz /run/systemd/resolve/stub-resolv.conf, który kieruje tradycyjnych klientów DNS do 127.0.0.53. Inny prawidłowy tryb łączy się z /run/systemd/resolve/resolv.conf, który bezpośrednio udostępnia znane serwery upstream, ale traci routing DNS dla każdego łącza systemd-resolved dla aplikacji, które odczytują ten plik bezpośrednio.

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Zwykły plik nie jest automatycznie błędny. NetworkManager lub inny menedżer resolverów może celowo przejąć nad nim kontrolę. Jeśli jednak ten host jest zaprojektowany do korzystania z trybu szczątkowego rozwiązywanego przez systemd, nieaktualny zwykły plik, nieaktualne dowiązanie symboliczne lub plik wskazujący na nieosiągalne serwery nazw może spowodować błędy wyszukiwania.

Przywróć zalecane łącze szczątkowe, gdy tryb szczątkowy jest zamierzony

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
ls -l /etc/resolv.conf
cat /etc/resolv.conf

Oczekiwane jest, że plik szczątkowy będzie widoczny nameserver 127.0.0.53. Jest to lokalny odbiornik, a nie serwer DNS nadrzędny. Użyj tego polecenia resolvectl status, aby sprawdzić, z którymi serwerami nadrzędnymi systemd-resolved faktycznie się skontaktuje. To rozróżnienie jest udokumentowane w podręczniku systemd-resolved Bookworm .

4. Sprawdź, czy systemd-resolved ma użyteczny serwer DNS

Uruchomić:

resolvectl status

Skoncentruj się na łączu, które przenosi trasę domyślną. Prawidłowa konfiguracja powinna zazwyczaj uwzględniać jeden lub więcej serwerów DNS dla tego łącza lub odpowiednie globalne serwery DNS. Jeśli nie ma dostępnego serwera DNS, samo naprawienie dowiązania symbolicznego nie pomoże: lokalny stub nie ma dokąd wysyłać zapytań.

Możesz przetestować resolver bezpośrednio:

resolvectl query debian.org

W podręczniku Debiana resolvectl udokumentowano status, query, flush-caches, oraz polecenia DNS dla poszczególnych łączy służące do inspekcji i rozwiązywania problemów.

5. Jeśli właścicielem interfejsu jest NetworkManager, napraw DNS w profilu połączenia

W instalacjach na komputerach stacjonarnych i wielu systemach Debian ogólnego przeznaczenia, NetworkManager może udostępniać dane DNS dla każdego łącza do systemd-resolved. Najpierw zidentyfikuj aktywny profil i aktualne wartości DNS:

nmcli connection show --active
nmcli device show

Jeśli DHCP dostarcza nieprawidłowy serwer DNS, zmień profil NetworkManager, zamiast edytować go /etc/resolv.confpo każdym ponownym uruchomieniu. Na przykład, jeśli Twoja polityka sieciowa zezwala na publiczne resolvery:

sudo nmcli connection modify "Wired connection 1"   ipv4.ignore-auto-dns yes   ipv4.dns "1.1.1.1 9.9.9.9"
sudo nmcli connection up "Wired connection 1"

Zastąp nazwę profilu i serwery DNS wartościami odpowiednimi dla Twojej sieci. Sieci korporacyjne, sieci VPN, środowiska Active Directory i konfiguracje z podzielonym DNS często wymagają wewnętrznych resolverów; publiczny DNS może uszkodzić prywatne nazwy hostów. Oficjalny dokument referencyjny konfiguracji NetworkManager dokumentuje jego integrację z systemd-resolved.

6. Jeśli interfejs jest własnością systemd-networkd, skonfiguruj DNS dla każdego łącza

W przypadku serwerów korzystających z systemd-networkd, umieść ustawienia DNS w odpowiednim .networkpliku w /etc/systemd/network/. Prosty przykład oparty na DHCP to:

[Match]
Name=ens160

[Network]
DHCP=yes
DNS=1.1.1.1
DNS=9.9.9.9
Domains=~.

[DHCPv4]
UseDNS=no

UseDNS=noMa to znaczenie, gdy chcesz zignorować serwery DNS dostarczane przez DHCP. Bez tego, serwer DNS DHCP jest używany domyślnie. Domains=~.to domena routingu tylko dla głównego serwera DNS, dzięki czemu łącze to nadaje się do zapytań, które nie pasują do bardziej szczegółowej domeny routingu. Nie dodawaj go bezmyślnie w systemach z wieloma adresami lub VPN, gdzie podział DNS jest celowy.

sudo systemctl restart systemd-networkd
resolvectl status ens160

Informacje na temat zachowania DNS=, Domains=, i DHCP UseDNS=znajdują się w podręczniku Debian Bookworm systemd.network .

7. Używaj globalnego pliku solved.conf tylko wtedy, gdy naprawdę chcesz mieć dostęp do DNS w całym systemie

/etc/systemd/resolved.conflub w sekcji „drop-in” /etc/systemd/resolved.conf.d/można zdefiniować serwery DNS systemu. Jest to przydatne w przypadku polityki obejmującej cały host, ale jest mniej precyzyjne niż konfiguracja dla każdego łącza na komputerach z sieciami VPN, wieloma interfejsami lub prywatnymi strefami DNS.

Lokalne dodawanie jest zazwyczaj bardziej przejrzyste niż edycja głównego pliku w stylu dostawcy:

sudo mkdir -p /etc/systemd/resolved.conf.d
sudoedit /etc/systemd/resolved.conf.d/10-dns.conf

Przykład:

[Resolve]
DNS=1.1.1.1 9.9.9.9

Następnie zastosuj:

sudo systemctl restart systemd-resolved
resolvectl status

W podręczniku Debian solved.conf wyjaśniono, że DNS=serwery DNS systemu i ustawienia administratora /etc/systemd/resolved.conf.d/mają pierwszeństwo przed konfiguracją o niższym priorytecie.

8. Opróżnij pamięć podręczną dopiero po naprawieniu konfiguracji bazowej

Nieaktualna pamięć podręczna może utrudniać rozwiązywanie problemów, ale opróżnianie pamięci podręcznej nie zastępuje naprawy niedostępnego serwera nadrzędnego lub uszkodzonej konfiguracji łącza. Po wprowadzeniu rzeczywistej zmiany w konfiguracji można uruchomić:

sudo resolvectl flush-caches
resolvectl query debian.org

W dokumentacji Systemd zaznaczono, że pamięć podręczna jest zwykle opróżniana automatycznie po zmianie konfiguracji sieci, więc wielokrotne ręczne opróżnianie pamięci podręcznej nie powinno być podstawowym rozwiązaniem.

9. Przeczytaj dziennik programu rozwiązującego błąd, jeśli błąd nadal występuje

Jeśli resolvectl statuswydaje się to rozsądne, ale zapytania nadal przekraczają limit czasu, sprawdź dziennik programu rozwiązującego problemy lokalne:

journalctl -u systemd-resolved -b --no-pager
journalctl -u systemd-resolved -b --no-pager | tail -n 50

Sprawdź, czy nie występują powtarzające się przekroczenia limitu czasu serwera, zmiany serwera zapasowego, błędy walidacji DNSSEC lub komunikaty wskazujące na ograniczone funkcje protokołu. Serwer resolwerowy może działać normalnie, podczas gdy jego skonfigurowany serwer nadrzędny jest niedostępny przez zaporę sieciową, sieć VPN, zasady routingu lub listę kontroli dostępu (ACL).

10. Sprawdź pełną ścieżkę wyszukiwania

Nie zatrzymuj się po jednym udanym resolvectlzapytaniu. Sprawdź ścieżkę używaną przez normalne aplikacje:

getent ahosts debian.org
resolvectl query debian.org
sudo apt update

getentjest przydatny, ponieważ wyszukiwanie nazw hostów w glibc podąża za hosts:linią w /etc/nsswitch.conf. Jeśli resolvectl querysię powiedzie, ale nie powiedzie, sprawdź konfigurację NSS. Podręcznik nss-resolvegetent Debiana opisuje opcjonalny moduł i zalecaną kolejność, która może kierować wyszukiwania nazw hostów w glibc przez systemd-resolved, zachowując jednocześnie mechanizmy awaryjne.libnss-resolve

Typowe objawy i najczęstsze miejsca, w których należy szukać

Zalecana kolejność naprawy

1. Sprawdź, czy istnieje podstawowa łączność sieciowa i domyślna trasa.
2. Sprawdź, czy systemd-resolvedfaktycznie zamierzasz zarządzać usługą DNS na tym hoście.
3. Sprawdź systemd-resolvedstan usługi i resolvectl status.
4. /etc/resolv.confPrzed zmianą sprawdź własność i tryb dowiązania symbolicznego.
5. Jeżeli tryb szczątkowy jest zamierzony, przywróć stub-resolv.confłącze.
6. Napraw upstream DNS u aktualnego właściciela: NetworkManager, systemd-networkd, DHCP, VPN lub globalnie rozwiązana konfiguracja.
7. Pamięć podręczną należy opróżnić dopiero po poprawieniu konfiguracji.
8. Sprawdź za pomocą resolvectl, getent, i aplikacji, która pierwotnie uległa awarii.

Kluczową zasadą jest własność: /etc/resolv.confsystemd-resolved i menedżer sieci są częściami jednego łańcucha resolverów. Trwała poprawka zmienia DNS na poziomie, który jest jej właścicielem, zamiast wielokrotnie zastępować ostatecznie wygenerowany plik.