DNSは「ネットワークの心臓部」。digを使い倒してトラブルの源流を突き止めろ
ネットワークエンジニアとして現場に立っていると、決まって「原因不明の通信断」という名の緊急コールが鳴り響く。現場に駆けつけ、パケットキャプチャを広げ、ログを睨みつける。その多くのケースで、犯人は「DNS」だ。
「名前解決ができていない」という事象一つとっても、それがキャッシュの汚染なのか、権威DNSサーバーの設定ミスなのか、あるいはTTL（Time To Live）の解釈違いなのか、原因は多岐にわたる。ブラウザの「サイトに接続できません」というエラーの裏側で、パケットがどんなドラマを繰り広げているか。それを可視化する最強の武器が dig コマンドだ。
今日は、教科書的な説明はすっ飛ばして、現場で泥臭く生き残るための「DNSクエリタイプ別診断術」を叩き込む。
なぜ nslookup ではなく dig なのか？
nslookup は既に枯れたツールであり、多くの環境で非推奨だ。dig（Domain Information Groper）が優れているのは、パケットの中身を「ありのまま」に表示してくれるからだ。DNSのレスポンスには、ヘッダー、質問部、回答部、権威部、追加情報部という構造がある。dig はこれらを忠実に再現し、今まさに通信がどこで詰まっているのかを明示してくれる。
現場で多用するDNSレコードとその診断法
実務では、単に dig google.com と叩くだけでは不十分だ。特定のレコードタイプを指定して、想定通りの応答が返っているかを確認する必要がある。
1. AレコードとAAAAレコード：通信経路の正体
Web APIの接続先IPが正しいか、IPv6の罠（デュアルスタック環境でIPv6が優先されて通信断になる等）を確認する際に必須だ。
# IPv4アドレスを取得
dig A example.com +short
# IPv6アドレスを取得
dig AAAA example.com +short+short オプションは、結果だけを抜き出したいときに重宝する。自動化スクリプトに組み込む際は、このフラグがあなたの指先を救うはずだ。
2. CNAMEレコード：たらい回しの追跡
「設定したはずなのに繋がらない」というトラブルの多くは、CNAMEの連鎖や、Alias設定の不整合だ。
# CNAMEの詳細を確認
dig CNAME api.service.comもし回答部(ANSWER SECTION)に CNAME が含まれていない場合、それは直接Aレコードが返っているか、あるいはレコードが存在しないことを意味する。
3. MXとTXT：メール配送とドメイン認証
メールが届かない、SPFやDKIMの検証エラーが消えない。そんな時はこれだ。
# メールサーバーの優先順位を確認
dig MX google.com
# SPFレコード等のTXTレコードを確認
dig TXT google.com特に TXT レコードは、外部の攻撃者がドメインをなりすましてメールを送っていないかを確認するSPF（Sender Policy Framework）のチェックで多用する。ここが1文字でもズレれば、君のメールは即座にスパム判定行きだ。
4. SOAレコード：ゾーンの「正しさ」を測る指標
SOA（Start of Authority）レコードは、そのゾーンの管理責任者やシリアル番号、更新間隔などが記された「ドメインの戸籍謄本」のようなものだ。
dig SOA example.comゾーン転送の同期が遅れている場合、このシリアル番号を各権威サーバー間で比較すれば、どこまでデータが伝播しているかが一目瞭然だ。
—
開発現場への還元：PythonでDNSを叩く
インフラ運用だけでなく、Web API設計の際にもDNSの挙動は無視できない。例えば、マイクロサービス間通信でDNSベースのロードバランシングを行う場合、Pythonの dnspython ライブラリを使って、プログラム側で名前解決を制御することもある。
import dns.resolver
# 特定のレコードタイプをクエリする例
def resolve_domain(domain, record_type='A'):
try:
answers = dns.resolver.resolve(domain, record_type)
for rdata in answers:
print(f"{record_type} record: {rdata.to_text()}")
except Exception as e:
print(f"DNSエラー発生: {e}")
# 'MX'レコードを取得してみる
resolve_domain('google.com', 'MX')障害対応の心得：まずは「どこ」に聞いているかを確認せよ
トラブルシューティングにおいて、一番やってはいけないのが「なんとなく」コマンドを打つことだ。dig を実行した際、出力の先頭にある SERVER: 行を見てほしい。今、君はどのDNSサーバーに問いかけているのか？
127.0.0.1だった場合：自身のキャッシュサーバーが犯人かもしれない。8.8.8.8だった場合：パブリックDNS経由で解決している。
もし特定の名前解決だけが失敗するなら、@ を使って特定の権威DNSサーバーを直接叩いてみるのが定石だ。
# 権威サーバーを直接指定してクエリ
dig @ns1.example.com example.com Aこうして、「自分のPCの設定ミス」なのか、「キャッシュサーバーの汚染」なのか、「権威サーバーの設定ミス」なのかを切り分ける。この泥臭いプロセスこそが、障害復旧までの時間を数分、あるいは数時間短縮する鍵になる。
教科書的な知識は「知っている」だけで終わるが、CLIでパケットを追いかけた経験は「血肉」となる。さあ、次は君のターミナルで、DNSの深淵を覗いてみてくれ。現場からは以上だ。
コメント