systemd-resolvedを使用してDebian 12で発生する「DNS解決の一時的な失敗」を修正する

このエラーはTemporary failure in name resolution、アプリケーションがホスト名（例：）をdeb.debian.orgIPアドレスに変換できなかったことを意味します。Debian 12 (Bookworm) では、これは必ずしもsystemd-resolvedが壊れていることを意味するわけではありません。Debian 12 では、DNS はデフォルトではインストールされずsystemd-resolved、代わりに NetworkManager、ifupdown、DHCP ツール、または別のリゾルバによって直接管理される場合があります。 を意図的に有効にしている場合はsystemd-resolved、設定を変更する前に、どのレイヤーでエラーが発生しているかを特定するのが最も迅速な解決策です。

この実用的なリファレンスは、 を使用する、または使用することを意図しているシステムに焦点を当てていますsystemd-resolved。Debian の Bookworm パッケージのドキュメントには、 をインストールするとsystemd-resolved 管理にsystemd-resolved切り替わると記載されています/etc/resolv.conf。サービス自体は にローカル DNS スタブを提供し、グローバル設定、リンクごとのネットワーク設定、DHCP、 、およびネットワーク管理サービス127.0.0.53からアップストリーム DNS 情報を受け取ります。Debian systemd-resolved パッケージのページとDebian systemd-resolved マニュアルを参照してください。resolvectl

クイック診断チェックリスト

1. 問題が一般的な接続性ではなく、DNSにあることを確認してください。

まずホスト名をテストし、次にIPアドレスをテストします。

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

ホスト名のルックアップが失敗し、直接IPアドレスのテストが成功した場合、DNSが障害の原因である可能性が高いです。両方とも失敗した場合は、まずインターフェース、ルート、ゲートウェイ、VLAN、Wi-Fi接続、ファイアウォール、またはアップストリームネットワークを確認してください。DNSの変更では、欠落しているデフォルトルートを修復することはできません。

より確実なルーティングチェックを行うには、以下も実行してください。

ip address
ip route

通常、想定されるインターフェースにはアドレスとデフォルトルートが設定されているはずです。インターフェース名はenp1s0、、、、またはその他となる場合があります。ens160eth0

2. systemd-resolvedが実際に使用されているかどうかを確認します。

マシンがsystemdを使用しているからといって、必ずしも存在するとは限りません。パッケージとサービスの両方を確認してください。

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

パッケージが存在せず、マシンに別の動作するDNS管理設計がある場合、インストールするsystemd-resolvedだけで必ずしも正しい解決策になるとは限りません。システムがそれを使用するはずで、サービスがインストールされているものの停止している場合は、それを有効にして起動してください。

sudo systemctl enable --now systemd-resolved

そのコマンドが失敗した場合は、サービスを繰り返し再起動する前にログを確認してください。

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

3. /etc/resolv.conf を置き換える前に内容を確認してください。

最もよくある設定ミスは、を/etc/resolv.conf独立したファイルとして扱うことです。を使用するとsystemd-resolved、サポートされている複数のモードで動作できます。アップストリームが推奨するスタブモードは/etc/resolv.confにリンクし/run/systemd/resolve/stub-resolv.conf、従来のDNSクライアントをに向けます127.0.0.53。もう1つの有効なモードはにリンクし/run/systemd/resolve/resolv.conf、既知のアップストリームサーバーを直接公開しますが、そのファイルを直接読み取るアプリケーションではsystemd-resolvedのリンクごとのDNSルーティングが失われます。

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

通常のファイルだからといって、必ずしも間違っているとは限りません。NetworkManager や他のリゾルバマネージャが意図的にそのファイルを所有している場合もあります。ただし、このホストが systemd-resolved のスタブモードを使用するように設計されている場合、古い通常のファイル、無効なシンボリックリンク、または到達不能なネームサーバを指すファイルがあると、名前解決に失敗する可能性があります。

スタブモードが意図されている場合は、推奨されるスタブリンクを復元してください。

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

nameserver 127.0.0.53スタブファイルに表示されるのは想定どおりです。これはローカルリスナーであり、アップストリームのDNSサーバーではありません。systemd resolvectl status-resolvedが実際にどのアップストリームサーバーに接続するかを確認するには、を使用してください。この違いについては、systemd-resolved Bookwormマニュアルに記載されています。

4. systemd-resolved に使用可能なアップストリーム DNS サーバーがあるかどうかを確認します。

走る：

resolvectl status

デフォルトルートを担うリンクに注目してください。正常な構成であれば、通常、そのリンクに対応する1つ以上のDNSサーバー、または適切なグローバルDNSサーバーが表示されます。使用可能なDNSサーバーが存在しない場合、シンボリックリンクを修正するだけでは解決しません。ローカルスタブにはクエリを送信する有効な場所がないためです。

リゾルバーを直接テストできます。

resolvectl query debian.org

Debianの resolvectl マニュアルには、status検査とトラブルシューティングに使用されるリンクごとの DNS コマンド、、、および が記載されていますquery。flush-caches

5. NetworkManagerがインターフェースを所有している場合は、接続プロファイルでDNSを修正します。

デスクトップ環境や多くの汎用Debianシステムでは、NetworkManagerがリンクごとのDNS情報をsystemd-resolvedに提供する場合があります。まず、アクティブなプロファイルと現在のDNS値を特定してください。

nmcli connection show --active
nmcli device show

DHCPが不正なDNSサーバーを提供している場合は、再起動のたびに編集するのではなく、NetworkManagerプロファイルを変更してください/etc/resolv.conf。たとえば、ネットワークポリシーでパブリックリゾルバが許可されている場合：

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を設定します。

を使用するサーバーの場合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を本当に必要とする場合にのみ、グローバルな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. 完全なルックアップパスを確認する

クエリが1回成功しただけで止めないでください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. このホスト上で実際にDNSを管理することを目的としたものかどうかを確認してくださいsystemd-resolved。
3. systemd-resolvedサービスの状態を確認し、 resolvectl status。
4. /etc/resolv.conf変更する前に、所有権とシンボリックリンクモードを確認してください。
5. スタブモードが意図的な場合は、stub-resolv.confリンクを復元してください。
6. 上流の DNS を実際の所有者 (NetworkManager、systemd-networkd、DHCP、VPN、またはグローバル解決済み設定) で修正してください。
7. 設定が修正された後にのみ、キャッシュをクリアしてください。
8. resolvectl、、getentおよび最初に失敗したアプリケーションで確認してください。

重要な原則は所有権です。systemd /etc/resolv.conf-resolvedとネットワークマネージャは、1つのリゾルバチェーンの一部です。永続的な修正では、最終的に生成されたファイルを繰り返し置き換えるのではなく、所有権を持つレイヤーでDNSを変更します。