【初心者向け】もう怖くない DNS：dig / nslookup / resolvectl 実践と安全トラブルシュート

🚀 はじめに：この記事でできること

DNSの基礎から実務で使う観測・切り分け手順、ローカル開発向けの設定までを、失敗しやすいポイントの回避策とセットで身につけます。

「DNSとは何か」を図解レベルで直感理解
dig / nslookup / resolvectlで原因の切り分け
Linuxでの/etc/resolv.confの扱いと設定の効かせ方を確認
軽量DNS（dnsmasq）でローカル開発の名前解決を構築
つまずきチェックリストで未然に防止

初心者でも安心：難しい用語は具体例とコマンドでフォローし、落とし穴は対策までセットで提示します。

🧭 前提：必要な環境と対象読者

本記事のコマンドはLinux/macOS/WSL2を中心に説明します。権限昇格（sudo）やネットワーク設定変更が含まれます。

必要な環境

Linux（Ubuntu/Debian/Fedora/Arch等）または macOS（Homebrew）
ネットワーク設定の変更権限（sudo）
パッケージ管理コマンド（apt / dnf / pacman / brew）

想定する読者

コマンドに抵抗がない初学者〜中級者
アプリ/インフラ開発で名前解決の切り分け力を高めたい人
ローカル開発で独自ドメインを使いたい人

ポイント
ディストリごとにパッケージ名が異なる場合があります（例：dnsutils / bind-utils）。後述の操作例で確認・置換してください。

💡 概要：DNSの仕組みとキーワード

DNSの全体像を短時間で掴み、後続の手順の理解を早めます。

DNSとは何か

DNS（Domain Name System）は、人が覚えやすい名前（example.com）をIPアドレス（93.184.216.34）へ変換する仕組み
役者：
- リカーシブDNS（再帰リゾルバ）：ユーザーの代わりに答えを探す代理人
- 権威DNS：ドメインの正解を持つサーバ
- キャッシュ：一度調べた答えをTTLの間だけ保存して高速化

DNSの基本的な流れ（概念図）

[あなたのPC]
     |
     | ①「example.com のIP教えて！」
     v
[リカーシブDNS（再帰DNS）]
     |
     | ② 権威DNSまで問い合わせを代理で実行
     v
[権威DNS（example.com の正解を持つ）]
     |
     | ③「正しいIPアドレスはこれ！」
     v
[リカーシブDNS]
     |
     | ④ 結果をPCに返す（キャッシュに保存）
     v
[あなたのPC]

問い合わせの実態（段階的解決）

[PC]
  |
  |-- ①「example.com のIP教えて？」
  v
[リカーシブDNS]
  |
  |-- ②「.（ルートDNS）教えて」
  v
[ルートDNS]
  |
  |-- ③「.com のDNSはここだよ」
  v
[TLD DNS (.com)]
  |
  |-- ④「example.com のDNSはこれ」
  v
[権威DNS（example.com）]
  |
  |-- ⑤「Aレコード（IPv4）は 93.184.216.34 だよ」
  v
[リカーシブDNS]
  |
  |-- ⑥ PCに返す（キャッシュする）
  v
[PC]

キャッシュ（高速化の要）

┌─────────────────────────────┐
│    リカーシブDNSのキャッシュのイメージ                   │
└─────────────────────────────┘
[キャッシュ DB]
  ├ example.com → 93.184.216.34（TTL 300秒）
  ├ google.com → 142.250.72.206（TTL 120秒）
  └ cloudflare.com → 104.16.133.229（TTL 180秒）
※ TTL が切れたら破棄して再問い合わせ

☆ キャッシュがある場合のフロー：
[PC]
  |
  |「example.com教えて」
  v
[リカーシブDNS]
  |
  |（キャッシュ確認 → まだ有効）
  |
  v
[PC] ← すぐ返る（高速）

DNSの役者（登場人物まとめ）

┌───────────────┬─────────────────────┐
│ DNSの役割                    │ 説明                                     │
├───────────────┼─────────────────────┤
│ PC（クライアント）           │ 「名前 → IP」の回答を受け取る者         │
│ リカーシブDNS                │ 問い合わせを代行してくれる代理人         │
│ ルートDNS                    │ 世界のDNSの最上位（13セット）            │
│ TLD DNS (.com等)             │ ドメインの種類を管理する局               │
│ 権威DNS（Authoritative）     │ ドメインの“正解”を持つサーバ           │
└───────────────┴─────────────────────┘

DNSレコードの種類（A・AAAA・CNAME・MX・TXT）

example.com の DNS レコード一覧（例）：
A      → IPv4（例：93.184.216.34）
AAAA   → IPv6（例：2606:2800:220:1:248:1893:25c8:1946）
CNAME  → 別名（example.com → www.example.com）
MX     → メールサーバ
TXT    → SPF/DKIM などのテキスト情報

レコード同士の関係イメージ：
example.com (A) ─────→ 93.184.216.34
www.example.com (CNAME) ─→ example.com
mail.example.com (MX) ──→ 10 smtp.example.com

🛠️ Step 1：ツールの導入と現在地の確認

必要なツールを入れて、いまどのDNSを参照しているかを素早く把握します。

1-1 必要ツールのインストール

# Ubuntu/Debian
sudo apt update
sudo apt install -y dnsutils ldnsutils systemd-resolved dnsmasq python3-pip
pip3 install --user dnspython

# Fedora
sudo dnf install -y bind-utils ldns systemd-resolved dnsmasq python3-pip
pip3 install --user dnspython

# Arch Linux
sudo pacman -Syu --noconfirm bind ldns systemd dnsmasq python-pip
pip3 install --user dnspython

# macOS (Homebrew)
brew install bind ldns dnsmasq python3
pip3 install --user dnspython

目的：dig/drill/dnsmasq/resolvectl/dnspython を利用可能にする
結果：各コマンドが--helpで応答し、後続手順が実行できる状態になる
注意：digはdnsutils（またはbind-utils）、drillはldnsutils（またはldns）に含まれます。ディストリによって名前が異なる場合があります

1-2 現在のDNS設定を観測

# systemd-resolved の状態
resolvectl status

# 名前解決の実体（スタブの可能性あり）
cat /etc/resolv.conf

# 上流DNSへの疎通（UDP/TCPで比較）
dig @1.1.1.1 example.com +short
dig @8.8.8.8 example.com +tcp +short

目的：ローカルがどのDNSを参照・中継しているかを把握し、上流疎通の有無を確認する
結果：/etc/resolv.confが127.0.0.53（スタブ）を向く環境や、公共DNSでの解決可否が分かる
補足：systemd-resolvedが有効な場合、/etc/resolv.confは自動生成されます

⚙️ Step 2：dig / nslookup / resolvectl の基本操作

よく使う問い合わせパターンを操作→目的→結果の順で最短理解します。

2-1 `dig` の定番クエリ

# Aレコード（IPv4）
dig example.com A +short

# AAAAレコード（IPv6）
dig example.com AAAA +short

# メール関連（MX）
dig example.com MX +short

# TXT（SPF/DKIM等で多用）
dig example.com TXT +short

# 権威までの経路を追う（トレース）
dig example.com +trace

# 公共DNSを明示指定（Cloudflare 1.1.1.1）
dig @1.1.1.1 example.com A +short

# 逆引き（IP→名前）
dig -x 93.184.216.34 +short

目的：レコード種別ごとの最小出力と、上流差分の切り分けを素早く行う
結果：+shortで機械処理しやすい出力、+traceで権威系までの流れを把握できる
ポイント：スクリプト化や監視への組み込みでは+shortが有用

2-2 `nslookup` / `drill` / `resolvectl`

# nslookup（対話モードを含む）
nslookup example.com
nslookup
> server 1.1.1.1
> set type=TXT
> example.com
> exit

# drill（軽量で高速）
drill example.com A

# systemd-resolved の問い合わせ
resolvectl query example.com

目的：環境に応じて代替ツールを使い分け、再現性の高い観測を行う
結果：対話モードや軽量ツールで条件を絞った確認が可能
補足：ツール間で出力形式が異なるため、比較時は同種のツールで揃えると混乱が減ります

📱 Step 3：実用シナリオ（切り分け・ローカルDNS・自動化）

現場でよくある課題を、操作→目的→結果→注意/補足の順で解決します。

3-1 「繋がらない/遅い」を5分で切り分け

# まずはデフォルトのリゾルバで
dig example.com A

# 公共DNSで比較（回線/ISP依存の問題を切り分け）
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short

# TCPでの再試行（フラグメント/MTU問題やUDPフィルタの切り分け）
dig @1.1.1.1 example.com A +tcp

# DNSSECの有無（応答に 'ad' フラグ）
dig example.com A +dnssec

# キャッシュをクリア（systemd-resolved）
sudo resolvectl flush-caches
resolvectl statistics

目的：ローカル設定・上流経路・伝送方式のどこで詰まっているかを即判定する
結果：UDPで失敗/TCPで成功→MTUやFWの可能性、公共DNSのみ成功→社内/ローカルDNSの問題と推定
ヒント：+tcpで成功するなら、FWやフラグメント周りの調整を検討

3-2 ローカル開発用に `dnsmasq` で独自ドメイン

設定ファイルを作成

# /etc/dnsmasq.d/dev.conf
# 公共DNSへフォワード
server=1.1.1.1
server=8.8.8.8

# ローカル開発用ドメイン（例：*.test.lan）
local=/test.lan/
domain=test.lan

# 固定名をローカルに解決
address=/api.test.lan/127.0.0.1
address=/web.test.lan/127.0.0.1

# システムの /etc/hosts も使う
expand-hosts

起動・自動起動

sudo systemctl enable --now dnsmasq
sudo systemctl status dnsmasq

OSをローカルDNSに向ける（NetworkManagerの例）

# /etc/NetworkManager/conf.d/00-dns.conf
[main]
dns=default

# DNSサーバを 127.0.0.1 に設定（接続プロファイル側でも可）
nmcli connection modify "<YourConnectionName>" ipv4.dns "127.0.0.1" ipv4.ignore-auto-dns yes
nmcli connection up "<YourConnectionName>"

# 確認
dig web.test.lan +short

目的：ローカル開発用のFQDNを安定して解決し、チームで共有しやすくする
結果：web.test.lanやapi.test.lanが127.0.0.1へ解決し、プロキシ/バックエンドの切り替えが容易
注意：Dockerは内部で127.0.0.11を使います。コンテナにローカルDNSを使わせるには--dns 127.0.0.1やComposeのdns:設定を明示

3-3 超手軽な上書き：`/etc/hosts`

# /etc/hosts
127.0.0.1 api.test.lan web.test.lan

目的：単発・即時の名前解決上書き
結果：対象ホスト名がローカルに解決される（共有には不向き）
使い分け：単発・即効性→/etc/hosts、複数名・共有→dnsmasqや社内DNS

3-4 Python（dnspython）で自動化

# pip install dnspython
import dns.resolver
for rtype in ["A", "AAAA", "MX", "TXT"]:
    try:
        answers = dns.resolver.resolve("example.com", rtype, lifetime=3.0)
        print(f"[{rtype}]")
        for r in answers:
            print(" ", r.to_text())
    except Exception as e:
        print(f"[{rtype}] error:", e)

目的：監視やCIでレコードの存在・遅延・変更を自動検知する
結果：種別ごとの応答/エラーが標準出力に整形され、ジョブの成否判定が容易
補足：lifetimeでタイムアウトを短く設定すると、ネットワーク劣化の検知が速くなります

⚠️ よくある落とし穴（対策付き）

冒頭でつまずきやすい論点をまとめ、すぐ取れる対策を添えます。

/etc/resolv.conf が上書きされる
- 生成元：NetworkManager、systemd-resolved、DHCPクライアント
- 対策：接続プロファイルで ipv4.ignore-auto-dns yes と手動DNS指定。resolvectl status で有効設定を確認
ゾーンのApex（ルート）にCNAMEを置く
- 多くのDNSで不正。ALIAS/ANAME対応のDNSを使うか、A/AAAAで定義
TTLが長すぎて切り替えが反映されない
- 切替前は一時的に**短いTTL（例：300秒）**へ
IPv6の逆引き/到達性で遅延
- AAAA優先時に疎通が不安定だと体感が悪化。IPv6疎通の確認・調整を実施
DoH/DoTの影響でローカルDNSが効かない
- ブラウザ/OS側の暗号化DNSを一時的に無効化して切り分け
Docker/K8sのDNS経路が独立
- Dockerは127.0.0.11、K8sはCoreDNS。別経路としてデバッグする
時刻ずれでDNSSEC検証が失敗
- NTPで時刻同期を有効化

✅ つまずきチェックリスト

dig @1.1.1.1 example.com +short は返るがデフォルトでは返らない → ローカル/社内DNSの問題を疑って切り分けた
+tcp なら成功する → UDP/53のフィルタ or フラグメント/MTU問題としてネットワーク側を調査した
resolvectl status で実際の参照DNSと/etc/resolv.confの生成元を把握した
/etc/resolv.conf を直しても戻る場合、**自動設定（NetworkManager/systemd-resolved）**を調整した
ブラウザだけ上書きが効かない場合、DoH/DoTを無効化して比較検証した
コンテナ内のみ解決不可のとき、Docker/K8sの別DNS経路で検証した
反映遅延があるとき、TTL短縮→切替→TTL戻しの手順を実施した
ゾーンのApexにCNAMEを置かず、ALIAS/ANAME or A/AAAAで定義した
DNSSEC関連の失敗時、時刻同期（NTP）と上流DNSの検証設定を確認した
dnsmasq 構成後、OS/コンテナの参照DNSが127.0.0.1になっていることを確認した
変更後に**リンク解決・画像表示・OGPプレビュー（SNSカード）**を実機で確認した

📚 参考リンク（公式中心）

IETF RFC（基礎仕様）
- RFC 1034: Domain Names - Concepts and Facilities
  https://www.rfc-editor.org/rfc/rfc1034
- RFC 1035: Domain Names - Implementation and Specification
  https://www.rfc-editor.org/rfc/rfc1035
systemd-resolved / resolvectl
- https://www.freedesktop.org/software/systemd/man/latest/systemd-resolved.service.html
- https://www.freedesktop.org/software/systemd/man/latest/resolvectl.html
dnsmasq
- http://www.thekelleys.org.uk/dnsmasq/doc.html
- https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
BIND / dig
- https://bind9.readthedocs.io/
- https://bind9.readthedocs.io/en/latest/manpages.html#dig
LDNS / drill
- https://www.nlnetlabs.nl/projects/ldns/about/
DNSの学習（入門）
- https://www.cloudflare.com/learning/dns/what-is-dns/
- https://developers.google.com/speed/public-dns
Python / dnspython
- https://www.dnspython.org/
- https://dnspython.readthedocs.io/

🔧 拡張案：次の一手

Unbound でキャッシング＋DNSSEC検証を構築し、セキュリティ/パフォーマンスを強化
DoH/DoTゲートウェイ（例：cloudflared）で暗号化DNSを導入
BIND/NSD/Knot で権威DNSを構築し、独自ゾーン運用（ALIAS/ANAMEの挙動も学ぶ）
Kubernetes の CoreDNS とService Discoveryを連携
CI/CDに dig +trace 検証を仕込み、DNS変更の安全性を自動チェック
監視＋通知（遅延/解決失敗）をPythonや外形監視で実装

🎯 まとめ

DNSは**“名前→数字”の変換装置**。リカーシブ・権威・キャッシュの三点で理解すると迷わない
dig/nslookup/resolvectlで現状を正しく観測できれば、切り分けが9割
/etc/resolv.confは自動更新を前提に、NetworkManagerやsystemd-resolvedと適切に連携
dnsmasqはローカル開発の強い味方。/etc/hostsは単発用途に割り切る
DoH/DoT・Docker/K8s・DNSSEC・TTLが**“効かない/遅い”の犯人**になりやすい
最後はチェックリストで未然に防止し、安定した開発/運用に繋げる

🚀 はじめに：この記事でできること#

🧭 前提：必要な環境と対象読者#

必要な環境#

想定する読者#

💡 概要：DNSの仕組みとキーワード#

DNSとは何か#

DNSの基本的な流れ（概念図）#

問い合わせの実態（段階的解決）#

キャッシュ（高速化の要）#

DNSの役者（登場人物まとめ）#

DNSレコードの種類（A・AAAA・CNAME・MX・TXT）#

🛠️ Step 1：ツールの導入と現在地の確認#

1-1 必要ツールのインストール#

1-2 現在のDNS設定を観測#

⚙️ Step 2：dig / nslookup / resolvectl の基本操作#

2-1 dig の定番クエリ#

2-2 nslookup / drill / resolvectl#

📱 Step 3：実用シナリオ（切り分け・ローカルDNS・自動化）#

3-1 「繋がらない/遅い」を5分で切り分け#

3-2 ローカル開発用に dnsmasq で独自ドメイン#

3-3 超手軽な上書き：/etc/hosts#

3-4 Python（dnspython）で自動化#

⚠️ よくある落とし穴（対策付き）#

✅ つまずきチェックリスト#

📚 参考リンク（公式中心）#

🔧 拡張案：次の一手#

🎯 まとめ#