概要
DNSが壊れています。端的に言えばそういうことです。このエラーはLinuxがホスト名をIPアドレスに解決できない場合に表示されます。curl、apt、ping、wgetなど、ドメイン名を使用するほぼすべてのコマンドで発生します：
$ curl https://example.com
curl: (6) Could not resolve host: example.com
$ ping google.com
ping: google.com: Temporary failure in name resolution
$ apt update
Err:1 http://archive.ubuntu.com/ubuntu focal InRelease
Temporary failure in name resolution
ネットワーク接続自体は通常問題ありません。原因のほとんどは、resolv.confが空または壊れている、systemd-resolvedがクラッシュしている、ネームサーバーの設定が間違っている、またはDNSが正しく設定されていないコンテナのいずれかです。
デバッグ手順
ステップ1 — DNS固有の問題か確認する
ホスト名ではなくIPアドレスでpingを送ります：
ping -c 3 8.8.8.8
成功した場合、ネットワークは正常でDNSの問題です。失敗した場合は、まずネットワークインターフェース、デフォルトゲートウェイ、ルーティングテーブルを確認してください。
ステップ2 — resolv.confを確認する
cat /etc/resolv.conf
正常なファイルには少なくとも1行のnameserverが含まれています：
nameserver 8.8.8.8
nameserver 1.1.1.1
ファイルが空？ファイルが存在しない？nameserver 127.0.0.53しかなく、そこで何もリッスンしていない？それが問題の原因です。
ステップ3 — systemd-resolvedが動作しているか確認する（Ubuntu/Debian）
systemctl status systemd-resolved
サービスが失敗または非アクティブな状態では、127.0.0.53で何もリッスンしていません。それが/etc/resolv.confの向き先です。その結果、DNSは無音で機能停止します。
ステップ4 — DNSを手動でテストする
# 特定のDNSサーバーに直接クエリを送る
nslookup google.com 8.8.8.8
# またはdig（より詳細な情報）
dig @8.8.8.8 google.com
正しく解決できた場合、ネームサーバー自体は動作しています。問題はLinuxのDNS到達設定にあり、サーバー側ではありません。
ステップ5 — Docker・コンテナ内を確認する
コンテナ内で実行している場合は、両方を確認します：
cat /etc/resolv.conf # コンテナ内
docker inspect | grep -i dns
ホスト側のDNS問題はコンテナにそのまま影響します。コンテナが正常な設定を引き継いでいると思い込まないでください。
解決方法
修正1 — resolv.confにネームサーバーを手動追加する（即時対処）
最も素早く解決できる方法で、あらゆるLinuxシステムで使えます：
sudo nano /etc/resolv.conf
以下を追加または置き換えます：
nameserver 8.8.8.8
nameserver 1.1.1.1
すぐにテストします：
ping -c 2 google.com
注意：systemd-resolvedやNetworkManagerで管理されているシステムでは、再起動時にこのファイルが上書きされます。設定を永続化するには、以下のいずれかの方法を使用してください。
修正2 — systemd-resolvedを再起動する（Ubuntu/Debian）
sudo systemctl restart systemd-resolved
sudo systemctl enable systemd-resolved
resolv.confをスタブリゾルバーに再リンクします：
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
修正3 — NetworkManager経由でDNSを設定する（デスクトップ/NM搭載サーバー）
# 接続一覧を表示
nmcli connection show
# アクティブな接続にDNSを設定（'eth0'を実際の接続名に変更）
nmcli connection modify eth0 ipv4.dns "8.8.8.8 1.1.1.1"
nmcli connection modify eth0 ipv4.ignore-auto-dns yes
nmcli connection up eth0
修正4 — /etc/systemd/resolved.confで永続的に設定する
systemd-resolvedの設定ファイルを直接編集します：
sudo nano /etc/systemd/resolved.conf
コメントを外して設定します：
[Resolve]
DNS=8.8.8.8 1.1.1.1
FallbackDNS=9.9.9.9
再起動して適用します：
sudo systemctl restart systemd-resolved
修正5 — DockerのDNS修正
/etc/docker/daemon.jsonを作成または編集します：
{
"dns": ["8.8.8.8", "1.1.1.1"]
}
Dockerを再起動します：
sudo systemctl restart docker
デーモン設定を変更せずに特定のコンテナだけ修正したい場合は、実行時にDNSを指定します：
docker run --dns 8.8.8.8 your-image
修正6 — WSL2固有の対処
WSL2はresolv.confを自動生成しますが、間違った内容になることがあります。まず自動生成を無効にします：
sudo nano /etc/wsl.conf
[network]
generateResolvConf = false
次に、ネームサーバーを手動で設定します：
sudo rm /etc/resolv.conf
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf
PowerShellからWSLを再起動します：wsl --shutdown
確認方法
# 基本的なホスト名解決
ping -c 3 google.com
# エンドツーエンドの確認
curl -I https://example.com
# 実際に使用されているDNSサーバーを確認
resolvectl status # systemd-resolvedのシステム
nslookup google.com # 応答したサーバーを表示
# aptの場合
sudo apt update
補足
VMやクラウド環境でよく見られるIP/サブネットの設定ミスとDNS問題が同時に発生している場合、ToolCraftのサブネット計算ツールを使うとCIDR範囲やネットワークアドレスの検証が素早くできます。静的IPを設定する際に、DNSの問題を追う前にゲートウェイが同じサブネット内にあるかを確認したいときに活用しています。
まとめと教訓
- まず
/etc/resolv.confを確認しましょう。約80%のケースは、ファイルが空か、機能していないスタブリゾルバーを指しているかのどちらかです。 - 管理されたシステムでは
resolv.confへの直接編集は一時的なものです。永続的な修正方法はDNSの管理者が誰か（systemd-resolved、NetworkManager、手動設定）によって異なります。 - Dockerコンテナは動作するDNS設定を自動的に引き継ぎません。ホストのDNS問題はそのまま伝播します。
daemon.jsonで明示的に設定し、自動引き継ぎを期待しないようにしましょう。 - WSL2は独自の対処が必要です。この問題が繰り返し発生する場合は、自動生成を無効にして
resolv.confを自分で管理しましょう。 ping 8.8.8.8は失敗するがping 127.0.0.1は成功する？DNSのデバッグをやめてください。それはネームサーバーではなく、ルーティングまたはゲートウェイの問題です。