Fix "Temporary Failure Resolving DNS" in Debian 12 with systemd-resolved

The error Temporary failure in name resolution means an application could not turn a hostname such as deb.debian.org into an IP address. On Debian 12 (Bookworm), that does not automatically mean systemd-resolved is broken. Debian 12 does not install systemd-resolved by default, and DNS may instead be managed directly by NetworkManager, ifupdown, DHCP tooling, or another resolver. If you have deliberately enabled systemd-resolved, the fastest fix is to identify which layer is failing before changing configuration.

This practical reference focuses on systems that use, or are intended to use, systemd-resolved. Debian's Bookworm package documentation says installing systemd-resolved switches /etc/resolv.conf to systemd-resolved management. The service itself provides a local DNS stub on 127.0.0.53 and accepts upstream DNS information from global configuration, per-link network configuration, DHCP, resolvectl, and network-management services. See the Debian systemd-resolved package page and Debian systemd-resolved manual.

Quick diagnosis checklist

1. Confirm that the problem is DNS, not general connectivity

Start by testing a hostname and then an IP address:

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

If the hostname lookup fails while the direct IP test succeeds, DNS is the likely fault domain. If both fail, first inspect the interface, route, gateway, VLAN, Wi-Fi association, firewall, or upstream network. A DNS change cannot repair a missing default route.

For a more deterministic routing check, also run:

ip address
ip route

You should normally have an address on the expected interface and a default route. The exact interface name may be enp1s0, ens160, eth0, or something else.

2. Check whether systemd-resolved is actually in use

Do not assume it is present just because the machine uses systemd. Check both the package and service:

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

If the package is absent and your machine has another working DNS-management design, installing systemd-resolved is not automatically the correct fix. If the system is supposed to use it and the service is installed but stopped, enable and start it:

sudo systemctl enable --now systemd-resolved

If that command fails, inspect the logs before repeatedly restarting the service:

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

3. Inspect /etc/resolv.conf before replacing it

The most common configuration mistake is treating /etc/resolv.conf as an isolated file. With systemd-resolved, it can operate in several supported modes. The upstream-recommended stub mode links /etc/resolv.conf to /run/systemd/resolve/stub-resolv.conf, which points traditional DNS clients at 127.0.0.53. Another valid mode links to /run/systemd/resolve/resolv.conf, which exposes known upstream servers directly but loses systemd-resolved's per-link DNS routing for applications that read that file directly.

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

A regular file is not automatically wrong. NetworkManager or another resolver manager may intentionally own it. However, if this host is designed to use systemd-resolved stub mode, a stale regular file, dangling symlink, or file pointing at unreachable nameservers can cause lookup failures.

Restore the recommended stub link when stub mode is intended

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

Seeing nameserver 127.0.0.53 in the stub file is expected. It is the local listener, not the upstream DNS server. Use resolvectl status to see which upstream servers systemd-resolved will actually contact. This distinction is documented in the systemd-resolved Bookworm manual.

4. Check whether systemd-resolved has a usable upstream DNS server

Run:

resolvectl status

Focus on the link that carries the default route. A healthy configuration should normally show one or more DNS servers for that link or suitable global DNS servers. If no usable DNS server is present, fixing the symlink alone will not help: the local stub has nowhere useful to send queries.

You can test the resolver directly:

resolvectl query debian.org

The Debian resolvectl manual documents status, query, flush-caches, and the per-link DNS commands used for inspection and troubleshooting.

5. If NetworkManager owns the interface, fix DNS in the connection profile

On desktop installations and many general-purpose Debian systems, NetworkManager may provide per-link DNS information to systemd-resolved. First identify the active profile and current DNS values:

nmcli connection show --active
nmcli device show

If DHCP is supplying a bad DNS server, change the NetworkManager profile rather than editing /etc/resolv.conf after every reboot. For example, if your network policy permits public resolvers:

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"

프로필 이름과 DNS 서버 값을 네트워크에 적합한 값으로 바꾸십시오. 기업 네트워크, VPN, Active Directory 환경 및 분할 DNS 설정에서는 내부 리졸버가 필요한 경우가 많습니다. 공용 DNS를 사용하면 개인 호스트 이름이 제대로 표시되지 않을 수 있습니다. NetworkManager의 공식 구성 참조systemd-resolved 문서에서 . 와의 통합에 대한 내용을 확인할 수 있습니다 .

6. systemd-networkd가 인터페이스를 소유하는 경우 링크별로 DNS를 구성하십시오.

DHCP를 사용하는 서버의 경우 systemd-networkd, DNS 설정을 해당 .network파일 에 배치하십시오 /etc/systemd/network/. 간단한 DHCP 기반 예는 다음과 같습니다.

[Match]
Name=ens160

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

[DHCPv4]
UseDNS=no

UseDNS=noDHCP에서 제공하는 DNS 서버를 무시하려는 경우에 중요합니다. 이 옵션을 사용하지 않으면 DHCP DNS가 기본적으로 사용됩니다. Domains=~.이 옵션은 DNS 루트에 대한 라우팅 전용 도메인으로, 더 구체적인 라우팅 도메인과 일치하지 않는 쿼리에 적합합니다. DNS 분할이 의도적인 멀티홈 또는 VPN 시스템에서는 이 옵션을 무턱대고 추가하지 마십시오.

sudo systemctl restart systemd-networkd
resolvectl status ens160

DNS=, Domains=, 및 DHCP 의 동작은 Debian Bookworm systemd.network 설명서UseDNS= 에 문서화되어 있습니다 .

7. 시스템 전체 DNS 설정이 정말 필요한 경우에만 global resolved.conf 파일을 사용하십시오.

/etc/systemd/resolved.conf또는 드롭인 옵션을 사용하여 /etc/systemd/resolved.conf.d/시스템 DNS 서버를 정의할 수 있습니다. 이는 호스트 전체 정책에 유용하지만 VPN, 여러 인터페이스 또는 개인 DNS 영역이 있는 시스템에서는 링크별 구성보다 정확도가 떨어집니다.

일반적으로 로컬에서 파일을 가져와 사용하는 방식이 공급업체에서 제공하는 방식의 메인 파일을 수정하는 것보다 깔끔합니다.

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

예:

[Resolve]
DNS=1.1.1.1 9.9.9.9

그다음 적용하세요:

sudo systemctl restart systemd-resolved
resolvectl status

Debian resolved.conf 매뉴얼에서는DNS= 이 파일이 시스템 DNS 서버를 제공하며, 관리자 드롭인 설정이 우선 /etc/systemd/resolved.conf.d/순위가 낮은 설정보다 우선한다고 설명합니다 .

8. 기본 설정을 수정한 후에만 캐시를 플러시하십시오.

오래된 캐시 데이터는 문제 해결을 어렵게 할 수 있지만, 캐시를 비우는 것은 연결할 수 없는 상위 서버나 손상된 링크 구성을 복구하는 것을 대체할 수 없습니다. 실제 구성 변경을 완료한 후에는 다음 명령을 실행하십시오.

sudo resolvectl flush-caches
resolvectl query debian.org

Systemd 자체 문서에 따르면 네트워크 구성이 변경될 때 캐시는 일반적으로 자동으로 플러시되므로 수동으로 반복적으로 플러시하는 것이 주요 해결 방법이 되어서는 안 됩니다.

9. 오류가 지속되면 리졸버 저널을 읽으십시오.

결과가 합리적으로 보이지만 쿼리 시간이 계속 초과되는 경우 resolvectl status, 부팅 로컬 리졸버 로그를 확인하십시오.

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

서버 시간 초과, 대체 서버 변경, DNSSEC 유효성 검사 실패 또는 프로토콜 기능 제한을 나타내는 메시지가 반복되는지 확인하십시오. 리졸버는 방화벽, VPN, 라우팅 정책 또는 네트워크 ACL로 인해 구성된 업스트림 서버에 연결할 수 없는 경우에도 정상적으로 실행될 수 있습니다.

10. 전체 조회 경로를 확인합니다.

한 번의 쿼리 성공에 만족하지 마십시오 resolvectl. 일반 애플리케이션에서 사용하는 경로를 확인하십시오.

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

getenthosts:glibc 호스트 이름 조회는 . 의 해당 줄을 따르기 때문에 유용합니다 /etc/nsswitch.conf. 만약 resolvectl query성공했지만 getent실패했다면 NSS 구성을 점검하십시오. Debian의 nss-resolve 설명서에는 선택적 libnss-resolve모듈과 glibc 호스트 이름 조회를 systemd-resolved를 통해 처리하면서도 대체 방법을 유지하는 권장 순서가 설명되어 있습니다.

흔한 증상과 가장 먼저 살펴볼 곳

권장 수리 순서

1. 기본 네트워크 연결 및 기본 경로가 존재하는지 확인하십시오.
2. systemd-resolved이 호스트에서 DNS를 관리하도록 의도된 것인지 확인하십시오 .
3. systemd-resolved서비스 상태를 확인하고 resolvectl status.
4. /etc/resolv.conf변경하기 전에 소유권과 심볼릭 링크 모드를 확인하세요 .
5. 스텁 모드를 사용하려는 경우 stub-resolv.conf링크를 복원하십시오.
6. 상위 DNS 설정을 실제 소유자(NetworkManager, systemd-networkd, DHCP, VPN 또는 전역 DNS 확인 구성)에서 수정하십시오.
7. 설정이 수정된 후에만 캐시를 비우십시오.
8. resolvectl, getent, 그리고 원래 오류가 발생했던 애플리케이션을 사용하여 확인하십시오 .

핵심 원칙은 소유권입니다. /etc/resolv.confsystemd-resolved와 네트워크 관리자는 하나의 리졸버 체인의 일부입니다. 영구적인 수정은 최종 생성된 파일을 반복적으로 교체하는 대신, 해당 파일을 소유하는 계층에서 DNS를 변경합니다.