【Ubuntu】DNSが引けない/遅い：dig/nslookup と resolv.conf/resolvectl の基本（原因切り分けの型）
この記事で解決できること
- 「ドメインが引けない」「急に遅い」を DNSが原因かどうか で切り分けできます
- Ubuntuで実際に使われているDNS設定（systemd-resolved / /etc/resolv.conf）を確認できます
- "DNSっぽい"症状（SSH/apt/curlが全部死ぬ）を最短で原因に寄せられます
結論（最短ルート）
DNSが怪しいときは、次の順番で見れば迷いません。
- 名前解決できるか：
dig example.com +short - どのDNSを使っているか：
resolvectl status（なければ/etc/resolv.conf） - DNSを指定して引いてみる：
dig @8.8.8.8 example.com +short - 遅い原因を分解：
dig +stats/time dig ... - 直す（最小変更）：DNSサーバ設定・systemd-resolved・ネットワーク側の問題を潰す
目次
前提（対象環境）
- OS：Ubuntu
- 対象：サーバ触り始めた新人
- 目的：トラブルシューティング（切り分けと復旧を優先）
1. DNSが怪しい典型症状（まず疑うべきパターン）
DNSが壊れると「全部が壊れた」ように見えます。
ssh user@hostnameが繋がらない（でもIP直打ちなら繋がる）curl https://example.comがCould not resolve hostで死ぬapt updateが失敗する（名前解決できない）- サーバが外部APIにアクセスできない（でもpingは通ることがある）
ポイント：IP直打ちで動くならDNS濃厚。
逆にIP直打ちでもダメなら、DNS以外（経路/FW/待受）を疑います。
2. まずは「引けるか」を確認（dig）
2-1. 最小確認（A/AAAAの結果）
$ dig example.com +short
出力例（IPが返る）：
93.184.216.34
出力が空・タイムアウトならDNS周りが怪しいです。
2-2. エラーの読み方（よく見る3つ）
NXDOMAIN：その名前は存在しない（スペルミス/ゾーン設定ミス）SERVFAIL：DNSサーバ側の障害/検証失敗（DNSSEC絡み含む）connection timed out; no servers could be reached：DNSサーバに到達できない（ネットワーク・FW・設定）
3. どのDNSサーバを使っているか確認（Ubuntuはここが罠）
Ubuntuは環境により、DNSが以下のどれかになります。
- systemd-resolved が管理（推奨されがち）
- NetworkManager が管理
- /etc/resolv.conf を直接参照（ただし多くは "リンク"）
3-1. resolvectl が使えるなら最優先で見る
$ resolvectl status
見るポイント：
DNS Servers:（実際に問い合わせる先）Current DNS Server:（現在使っている先）
3-2. /etc/resolv.conf を確認（ただし"リンク"が多い）
$ cat /etc/resolv.conf $ ls -la /etc/resolv.conf
出力例：
nameserver 127.0.0.53
これは systemd-resolved のローカルスタブ です。実際の上流DNSは resolvectl status に出てきます。
4. DNSサーバを指定して引く（ここで原因が分解できる）
4-1. Google Public DNSで引く（例）
$ dig @8.8.8.8 example.com +short
4-2. Cloudflareで引く（例）
$ dig @1.1.1.1 example.com +short
4-3. この結果の解釈が重要
- 指定DNSだと引ける → あなたの環境が使っているDNSが壊れてる/到達できない
- 指定しても引けない → もっと手前（ネットワーク/経路/出口）に問題がある可能性
「自分のDNSはダメだが、8.8.8.8ならOK」→ DNSサーバ設定を変えると復旧する可能性が高いです。
5. "遅い"を測る（体感は嘘をつきます）
DNSは「引けるけど遅い」が普通にあります。時間を測って分解します。
5-1. digの統計を見る
$ dig example.com +stats
最後にこういう行が出ます：
Query time: 250 msec
5-2. time で複数回測る（キャッシュの影響を見る）
$ time dig example.com +short $ time dig example.com +short
- 1回目だけ遅い → キャッシュ/初回解決
- 毎回遅い → DNSサーバ品質/ネットワーク/MTU/出口
6. よくある原因パターンと"次の一手"
パターン1：systemd-resolved が死んでる
$ systemctl status systemd-resolved $ sudo systemctl start systemd-resolved $ sudo journalctl -u systemd-resolved -n 200
パターン2：DNSサーバが落ちている・遠い
dig @8.8.8.8 ... が速い → DNSサーバが遅い/不調
パターン3：FW/出口制御で53/UDPが塞がれている
dig @8.8.8.8 がタイムアウト → そもそも外部DNSへ出られない可能性
パターン4：検索ドメイン（search）が悪さして遅い
短いホスト名で引こうとして、何度も検索して遅くなることがあります。
7. 最小の復旧手段（安全優先）
7-1. まずは現状を記録（戻せるように）
$ date $ resolvectl status || true $ cat /etc/resolv.conf
7-2. どうしても緊急で直す：/etc/resolv.conf を直接書き換える（非推奨だが即効性）
注意：上書きされる可能性があります。恒久対策ではありません。
$ sudo cp -a /etc/resolv.conf /etc/resolv.conf.bak $ printf "nameserver 1.1.1.1\nnameserver 8.8.8.8\n" | sudo tee /etc/resolv.conf $ dig example.com +short
元に戻す：
$ sudo cp -a /etc/resolv.conf.bak /etc/resolv.conf
8. 失敗例と読み解き
8-1. dig example.com が NXDOMAIN
ドメイン名ミス、DNSゾーン未設定、移管ミス
8-2. dig @8.8.8.8 ... もタイムアウト
そもそも外に出られていない/53が塞がれている
8-3. "引けるけど遅い"
DNSサーバ品質、検索ドメイン、IPv6/AAAA待ち、経路
9. やってはいけないこと
やってはいけない1：原因不明のまま /etc/resolv.conf を永続設定扱いする
上書きされることが多く、再起動で戻って混乱します。
やってはいけない2：DNSの問題を "アプリの不具合" と決めつけて時間を溶かす
IP直打ちで動くならDNSが濃厚です。先にDNSを潰すべきです。
やってはいけない3：遅いのに測らない
dig +stats でQuery timeを見て、比較してください。体感は当てになりません。
コピペ用：DNS切り分けテンプレ
# 1) 引けるか dig example.com +short # 2) DNS設定（systemd-resolved想定） resolvectl status || true cat /etc/resolv.conf # 3) 指定DNSで引く（比較） dig @1.1.1.1 example.com +short dig @8.8.8.8 example.com +short # 4) 遅さを見る dig example.com +stats dig A example.com +stats dig AAAA example.com +stats
まとめ
- DNSは「引けない」より「遅い」が厄介。測って分解する
dig→resolvectl→dig @DNSの順が最短- まず復旧したいなら一時的にDNSを差し替える手もあるが、恒久対策は管理系で
検証環境
本記事のコマンドは Ubuntu 24.04 LTS / bash 5.2 で動作確認済みです。