深夜のデータセンター、冷房の唸り声と赤く点滅する警告灯の先にあるのは、いつも「DNSの迷宮」だ。
「Web APIが繋がらない」「名前解決がときどきタイムアウトする」。そんなヘルプデスクからのチケットが上がってきたとき、若手エンジニアの多くは、とりあえず ping を打って、次にブラウザを開いて確認する。だが、それで解決した試しがあるか？
DNSはネットワークの「背骨」だ。ここが正しく機能していない状態で通信を語るのは、地図を持たずに暗闇のジャングルを走るようなものだ。今日は、DNSのトラブルシューティングにおいて、僕が必ず最初に行う「dig を使った深層診断」について話をしよう。
再帰検索（+recurse）vs 非再帰検索（+norecurse）
DNSの仕組みを理解する上で、最も重要なのが「問い合わせのスタンス」だ。普段皆さんが使っている dig は、デフォルトで +recurse（再帰問い合わせ）が有効になっている。
これは、宛先のDNSサーバーに対して「お前が知らないなら、知っている奴に聞きに行って俺に教えてくれ」と依頼するモードだ。これに対し、+norecurse（非再帰問い合わせ）は「お前が持っているキャッシュやゾーンファイルの中身だけを答えろ。余計な足を使うな」と命じるモードである。
この使い分けが、障害切り分けの「鍵」になる。
なぜ +norecurse が必要なのか？
例えば、特定のドメインが「キャッシュポイズニング」や「委任設定の不備」を起こしている可能性があるとき、再帰問い合わせをしても、どこかのキャッシュサーバーが汚れた情報を返してくるだけで、真犯人（権威DNSサーバー）に辿り着けない。
ここで +norecurse を使い、権威サーバーを直接叩くことで、「現在、インターネット上のどこで名前解決が詰まっているのか」を暴き出すのだ。
実践：dig による権威サーバーへの直撃診断
まず、あるドメインの権威サーバーがどこにあるかを調べ、そこに非再帰問い合わせを投げる手順を見てみよう。
# 1. まずは権威サーバー（NSレコード）を特定する
dig ns example.com +short
# 2. 特定した権威サーバー（例: ns1.example.com）に対して非再帰で問い合わせる
# @ を使ってターゲットを指定し、+norecurse (+nsrd) を付与する
dig @ns1.example.com example.com +norecurseもし、この結果で status: NOERROR が返ってこない、あるいは期待する ANSWER SECTION が空であれば、その権威サーバーの設定ファイルが間違っているか、ゾーン転送が失敗している可能性が高い。
現場で使う「デバッグ・ワンライナー」
僕はトラブルシューティング中、以下のようなコマンドをよく使う。
# 権威サーバーに対して、レコードタイプを指定して詳細を聞く（トレース機能付き）
# +trace は再帰的にルートサーバーから辿るため、委任（Delegation）のミスを探すのに最適
dig example.com NS +trace
# 特定のキャッシュサーバーが正しい情報を保持しているか確認する
# @8.8.8.8 を指定し、あえて再帰を無効にすることで、Googleのサーバーが何を「知っているか」を覗き見る
dig @8.8.8.8 example.com +norecurseコードからDNSを制御する：Pythonでの実装例
APIの開発時、特定のDNSサーバー経由で名前解決を行いたいケースがある。Pythonの dnspython ライブラリを使えば、dig と同じような制御が可能だ。これは環境依存のDNS設定を無視して、明示的に指定したDNSサーバーに問い合わせる際に重宝する。
import dns.resolver
def check_dns_record(domain, dns_server):
# リゾルバーオブジェクトの作成
resolver = dns.resolver.Resolver()
# 問い合わせ先を明示的に指定
resolver.nameservers = [dns_server]
try:
# 非再帰的な挙動をシミュレート（rd=False）
answers = resolver.resolve(domain, 'A', rd=False)
for rdata in answers:
print(f"IP: {rdata.address}")
except Exception as e:
print(f"DNS query failed: {e}")
# Google DNSを使ってexample.comのAレコードを直接問い合わせる
check_dns_record('example.com', '8.8.8.8')最後に：ネットワークエンジニアの「勘」を養うために
DNSのトラブルは、多くの場合「設定の伝播遅延（TTL）」か「上位サーバーへの委任設定の不備」だ。
+recurse だけで満足せず、+norecurse を使って権威サーバーの生の声を聞く癖をつけてほしい。通信が繋がらないとき、パケットがどこで弾かれ、誰が誤った情報を返しているのか。その「経路」を可視化できる能力こそが、シニアエンジニアとそうでない者の決定的な差だ。
ログを眺める前に、まずは dig を叩け。パケットは嘘をつかない。たとえ夜中の3時であっても、DNSのレスポンスだけは常に真実を告げているのだから。
コメント