Debian 12 DNSルックアップの失敗: systemd-resolvedの修復

Debian 12で「名前解決に一時的な失敗が発生しました」と表示される場合は、リゾルバサービス、リンク/etc/resolv.conf、およびDNSサーバーをresolvectlこの順序で確認してください。サービスの再起動は、サービスが停止している場合にのみ有効です。リンク切れやアップストリームサーバーへの接続障害の場合は、別の対処が必要です。

これらの手順は、 を使用するように構成された Debian 12 (Bookworm) システムに適用されますsystemd-resolved。Debian は、このリゾルバを別のパッケージに分割し、デフォルトにはしていません。これは、Debian 12 リリース ノートで説明されています。インストールで別の DNS マネージャーを使用している場合は、これらの設定を強制的に適用するのではなく、そのマネージャーに制御を任せてください。

1. 名前解決が失敗する箇所を特定する

ネットワーク経路とホスト名のルックアップから始めます。コマンドはローカル環境、またはネットワーク状況の変化があっても開いたままになるターミナルで実行してください。

ip -br address
ip route
ping -c 2 1.1.1.1
resolvectl status
resolvectl query debian.org
getent ahosts debian.org

デフォルトルートと正常に動作する数値IP接続は、マシンがDNSなしでネットワークに到達できることを示唆しています。pingが失敗しただけでは、ルートが壊れていることを証明するものではありません。ネットワークはICMPエコー応答をブロックする可能性があるためです。インターフェースにアドレスまたはルートがない場合は、まずネットワーク接続を修正してください。

resolvectl statusグローバルまたは個々のインターフェースに割り当てられた DNS サーバーとドメインを表示します。systemdresolvectl queryリゾルバをテストします。Linuxgetent ahostsアプリケーションで一般的に使用されるホスト名ルックアップパスをテストします。この違いは、障害の特定に役立ちます。

2. systemd-resolvedがインストールされ、有効になっていることを確認してください。

Debian 12では、systemdが存在していても、個別のリゾルバパッケージがインストールされているとは限りません。DNSファイルを変更する前に、パッケージとユニットを確認してください。

dpkg-query -W -f='${Status}\n' systemd-resolved
systemctl status systemd-resolved --no-pager

パッケージがインストールされているがサービスが非アクティブになっている場合は、サービスを開始して、今後の起動時に有効にします。

sudo systemctl enable --now systemd-resolved
systemctl is-active systemd-resolved

最終コマンドは、以下の内容を報告するはずですactive。ユニットが故障した場合は、繰り返し再起動するのではなく、実際のエラーメッセージを確認してください。

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

パッケージが見つからない場合は、sudo apt install systemd-resolvedパッケージリポジトリへのアクセスが正常に機能するようになってからインストールしてください。このパッケージをインストールすると/etc/resolv.conf、の制御が変更されるため、NetworkManager、VPN、または静的 DNS の設定を事前に確認してください。Debian はこのパッケージの変更についてBookworm のアップグレードノートで説明しています。

3. リゾルバリンクが間違っている場合にのみ修復する

標準systemd-resolvedスタブは でリッスンします127.0.0.53。推奨される互換性ファイルは で/run/systemd/resolve/stub-resolv.conf、 からリンクできます/etc/resolv.conf。まず現在のモードを確認してください。

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
resolvectl status

リンクもサポートされているモードですが、これを使用するプログラムはローカルスタブではなく、アップストリームのDNSに直接接続します。単に異なるという理由だけで、そのリンクが壊れていると判断しないでください。サポートされているモードについては、/run/systemd/resolve/resolv.confDebian systemd-resolvedサービスのマニュアルを参照してください。

意図的にローカルスタブを使用している場合、サービスが実行中で、スタブリスナーが有効になっており、既存の/etc/resolv.confリンクが欠落している、宙ぶらりんになっている、または古いリゾルバを指している場合は、推奨されるリンクを復元してください。まず、既存のファイルまたはリンクをバックアップします。ファイルが存在しない場合は、コピーをスキップします。

sudo cp -a /etc/resolv.conf /etc/resolv.conf.dns-backup
sudo ln -sfn /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
cat /etc/resolv.conf

別のサービスが意図的に管理しているホストでは、その代替処理を実行しないでください/etc/resolv.conf。ローカルnameserver 127.0.0.53エントリには、動作するスタブリスナーも必要です。単にアドレスを書き込むだけでは、DNSサービスは作成されません。リモートマシンでは、リゾルバ設定を編集する前に、別のアクセス方法を確保してください。

4. 存在しない、または到達不能な上流DNSサーバーを修正する

適切なアップストリーム DNS サーバーが表示されない場合、または設定済みのサーバーに到達できない場合はresolvectl status、その割り当て元を修正してください。動的 DNS 設定は、DHCP、NetworkManager、systemd-networkd、または VPN から取得される場合があります。デフォルト ルートを伝送するインターフェースと、そのインターフェースに属する DNS サーバーを確認してください。

パブリックDNSを許可するネットワークで簡単な診断テストを行うには、既知のパブリックリゾルバをそのインターフェースに割り当てます。ens33実際のインターフェースに置き換えてくださいip -br address。

sudo resolvectl dns ens33 1.1.1.1 1.0.0.1
resolvectl query debian.org

これらの2つのアドレスは、Cloudflareの公開DNSリゾルバアドレスとして文書化されています。このresolvectl dns変更は実行時設定であり、ネットワーク管理者がリンク再接続時に元に戻す可能性があります。ルックアップが正常に機能する場合は、この一時的なコマンドに頼るのではなく、永続的なDNSソースを修正してください。

NetworkManager を使用する場合は、アクティブな接続を検査しnmcli connection show --active、その接続の DNS 設定または DHCP 動作を調整します。systemd-networkd を使用する場合は、目的のDNS=設定を対応するファイルに記述し.network、安全なタイミングでネットワークをリロードまたは再構成します。詳細については、Debian systemd.network マニュアルおよびDebian NetworkManager 設定マニュアルを参照してください。管理対象インターフェイスを再接続すると、SSH セッションが中断される場合があります。

内部名には、組織または VPN の DNS サーバーを優先してください。パブリック リゾルバはプライベート ゾーンに応答するとは限らないため、すべてのクエリをパブリック リゾルバに強制すると、スプリット DNS が壊れるか、内部ホスト名が漏洩する可能性があります。グローバルDNS=エントリは、リンクごとの DNS を自動的に置き換えるのではなく、リンクごとの DNS と並行して動作させることができます。詳細については、 Bookworm resolved.conf マニュアルresolved.confを参照してください。

5. キャッシュをクリアし、両方のルックアップパスが機能することを確認します。

サービス、リゾルバリンク、またはアップストリーム構成を修正した後、キャッシュされた応答をクリアして再テストしてください。

sudo resolvectl flush-caches
resolvectl query debian.org
getent ahosts debian.org
resolvectl status

修復が有効であるかどうかは、resolvectl queryアドレスが返され、getent ahostsアドレスレコードが返され、ネットワーク再接続後も目的のDNSサーバーが引き続き表示されるかどうかで判断できます。2つのコマンドは異なるインターフェースをテストするため、一方のコマンドが成功したからといって、すべてのアプリケーションが修復されたとは限りません。Debianのresolvectlマニュアルには、クエリ、ステータス、キャッシュのフラッシュに関する説明が記載されています。

resolvectl query成功したがそれでも失敗する場合はgetent、grep "^hosts:" /etc/nsswitch.conf適切なNSSモジュールdnsまたはインストール済みのresolveNSSモジュールがルックアップパスにあることを確認してください。両方とも失敗し続ける場合は、リゾルバジャーナルとDNSトラフィックに対するファイアウォールの制限を確認し、実際の企業、ルーター、またはプロバイダのDNSアドレスを使用してテストしてください。ルックアップが一度成功しただけでは不十分です。再接続後と再起動後にチェックを繰り返して、永続的な修正が行われたことを確認してください。