名前が解決されない（DNS）

この障害の症状には見覚えがあります。ping 1.1.1.1 は通るのに、ping millida.net は「Temporary failure in name resolution」を返し、apt update はハングしてタイムアウトします。ネットワーク自体は正常で、壊れているのは名前からアドレスへの変換だけです。

ステップ1. 問題が名前解決にあることを確認する

ping -c3 1.1.1.1
getent hosts millida.net
dig +short millida.net @1.1.1.1

サーバーを明示した dig は応答するのに getent が応答しない場合、システムはどのリゾルバに問い合わせればよいかを把握していません。これは接続性の問題ではなく、設定の問題です。

ステップ2. 名前解決を担っているものを確認する

cat /etc/resolv.conf
systemctl status systemd-resolved
resolvectl status

考えられる状況は3つあります。

• ファイルが空か、nameserver 行が存在しない — リゾルバが設定されていません。
• ファイルに nameserver 127.0.0.53 が含まれているが、systemd-resolved が動作していない — リクエストはどこにも届きません。
• 当社のネットワークから到達できないサードパーティのサーバーが設定されています。

ステップ3. 修正する

apt と curl を復旧させるための応急処置は次のとおりです。

echo 'nameserver 1.1.1.1' > /etc/resolv.conf
echo 'nameserver 8.8.8.8' >> /etc/resolv.conf

すぐに動作しますが、再起動または次回のネットワーク再設定までしか持ちません。恒久的な修正はシステムによって異なります。

systemd-resolved を使用する Debian と Ubuntu の場合:

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
resolvectl dns ens18 1.1.1.1 8.8.8.8

AlmaLinux と CentOS Stream の場合:

nmcli con mod "System ens18" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli con up "System ens18"

/etc/resolv.conf が /run へのシンボリックリンクである場合は、手動で編集しないでください。そのようなファイルはサービスによって上書きされ、変更は最初の再起動で消えてしまいます。1週間後に同じ障害に遭遇しても、原因を思い出せないでしょう。

ステップ4. 特殊なケース

リゾルバは動作しているのに、特定の名前だけが見つからない場合。そのレコードがそもそも公開されているかを確認してください。

dig millida.net A @1.1.1.1
dig millida.net A @8.8.8.8

2つのサーバーから異なる応答が返る場合、ゾーンが最近変更され、どこかに古いキャッシュがまだ残っていることを意味します。dig の応答にあるレコードの有効期間（TTL）だけ待ってください。

マシンのアドレスに対する逆引きレコード（PTR）はこの問題とは無関係です。これはメールサーバーが必要とするもので、「アクセス」タブで設定し、マシン自身が名前を解決する方法には影響しません。

もうよくある発見は、移行後に残った古い行が書かれた /etc/hosts です。システムは DNS より先にこれを確認するため、頑なに古いアドレスへ接続し続けます。

cat /etc/hosts

余分な行を削除し、127.0.0.1 localhost とマシン自身の名前が書かれた行だけを残してください。

どのサーバーからも名前解決できない場合

その場合、問題はより広範です。記事マシン上のネットワーク消失を使用して基本的な接続性を確認し、送信ポート53が自身のパケットフィルターによってブロックされていないことを確認してください。