【実務・中級編】 digコマンドによる詳細なDNSレコード照会とトレース機能(+trace) – トラブルシューティング＆ネットワーク運用監視実践ガイド

現場のDNSトラブルは「深層」を覗かなければ解決しない：dig +trace が教える真実

ネットワークエンジニアとして夜通しトラブルシューティングをしてきた経験上、最も恐ろしいのは「自分の端末から見える景色」だけを信じてしまうことだ。

「さっきまで疎通していたAPIが、突然名前解決できなくなった」。そんな悲鳴のようなチケットが上がったとき、駆け出しのエンジニアは真っ先に ping を打ち、次に nslookup で「引けない」と嘆く。だが、それで何が分かる？ DNSは世界中に散らばる階層構造の物語だ。一部のキャッシュサーバーが誤った情報を握っているのか、それとも権威サーバーの委任（Delegation）が壊れているのか。

今日は、そんなDNSの深淵を覗き込み、迷宮入りのトラブルを一撃で仕留めるための相棒、dig +trace について語ろう。

—

なぜ「ただのdig」では不十分なのか

通常の dig example.com は、システムの /etc/resolv.conf に記述されたフルリゾルバ（DNSキャッシュサーバー）に対して問い合わせを行う。これは「答えを教えてもらう」行為に過ぎない。

だが、障害はしばしば「答えを教えてくれるまでの経路」に潜んでいる。特定のネームサーバーの設定ミス、あるいは上位ドメインからの委任情報の不整合など、フルリゾルバがキャッシュしている「間違った過去の栄光」に惑わされると、真の原因には一生たどり着けない。

そこで登場するのが dig +trace だ。これは、ルートサーバー（.）から順に権威DNSサーバーを自ら辿り、委任パスを全て検証するコマンドだ。DNSサーバーが「誰に聞けばいいか」をどう伝搬しているのか、その全貌を可視化してくれる。

—

実戦：dig +trace の読み解き方

実際にコマンドを叩くと、膨大な情報が流れてくる。まずは基本のコマンドを叩いてみてほしい。

# 権威サーバーまでの委任パスを追跡する
dig +trace example.com

出力結果の後半、特に以下のセクションに注目してほしい。

1. NSレコードの確認: どのネームサーバーがドメインの権威を持っているか。
2. Glueレコード: 権威サーバー自身がドメイン内に存在する場合、そのIPアドレスをどう解決しているか。
3. 委任の連鎖: . → com. → example.com. と、どのサーバーが次のバトンを渡しているか。

もし、途中のサーバーで NXDOMAIN が返ったり、期待しないIPアドレスが提示されたりすれば、そこが障害の発生源だ。「犯人は、キャッシュサーバーではなく、権威サーバーの設定ファイル（ゾーンファイル）にある」と断定できる瞬間である。

—

アプリケーション開発者が知っておくべき「DNSの挙動」

Web APIを開発する際、DNSの問題をアプリケーション側でどうデバッグするか。例えば、Pythonで特定のDNSサーバーを直接叩いて検証したい場合、標準ライブラリではなく dnspython を使うのがプロの流儀だ。

import dns.resolver

# 特定の権威サーバーを指名して問い合わせを行う
resolver = dns.resolver.Resolver()
resolver.nameservers = ['198.41.0.4']  # 例: ルートサーバー (a.root-servers.net)

try:
    # Aレコードを直接取得する
    answers = resolver.resolve('example.com', 'A')
    for rdata in answers:
        print(f"IPアドレス: {rdata.address}")
except Exception as e:
    print(f"解決失敗: {e}")

また、curl で接続先を強制的に指定してテストする際も、DNSの問題かサーバー自体の問題かを切り分けるために、--resolve オプションは必須のスキルだ。

# DNSを介さず、特定のIPアドレスに対して直接ホスト名を指定してアクセスする
curl -v --resolve example.com:443:93.184.216.34 https://example.com/

—

現場で役立つ「+trace」活用のTips

最後に、現場で私が後輩によく教える「泥臭い」Tipsを共有する。

タイムアウトを疑え: +trace が途中で止まる場合、UDPのパケットサイズ制限（EDNS0）によるドロップが疑われる。+bufsize=4096 を付与して再試行してみよう。
権威サーバーの不一致: dig +trace で表示されるNSリストと、レジストラ（お名前.comやAWS Route53など）の設定が食い違っていることは驚くほど多い。これは「キャッシュのせい」ではなく「管理者の設定ミス」だ。
TTLを無視しない: dig の出力には TTL が表示される。もし頻繁にDNSレコードを変更する運用をしているなら、TTLの長短がキャッシュサーバーの「粘り」を左右することを常に念頭に置くこと。

最後に：ネットワークを「観る」ということ

DNSは単なる辞書ではない。インターネットという巨大なネットワークを結びつける、動的な神経系だ。dig +trace を使いこなすということは、この神経系に流れるシグナルを正しく読み取る能力を養うことに他ならない。

ツールに頼り切るのではなく、ツールを通じて「インターネットの成り立ち」を想像してほしい。そうすれば、どんな複雑な障害も、パケットの挙動として冷静に紐解けるようになるはずだ。

さあ、次は君が現場でそのコマンドを打ち、迷宮の出口を見つける番だ。健闘を祈る。