【実務・中級編】 digコマンドの出力構造とSECTION(QUESTION, ANSWER, AUTHORITY, ADDITIONAL)の解説 – トラブルシューティング＆ネットワーク運用監視実践ガイド

DNSが「繋がらない」時の解像度。digのセクションを読み解き、真因を突き止める技術

システム運用において、最も頭を抱えるのが「名前解決ができない」という報告だ。ブラウザで404が出るならまだマシだが、DNSの不調はサイトそのものがブラックホールに消えたかのような絶望感をエンジニアに与える。

多くのジュニアエンジニアは、とりあえず ping を打ってパケットの消失を確認し、次に nslookup を叩く。だが、現場で本当に頼りになるのは dig だ。DNSの「生の挙動」をありのままに暴き出すこのツールを使いこなせるかどうかで、障害復旧までの時間は劇的に変わる。

今日は、dig の出力結果にある4つのセクションを、現場で叩き上げられた視点から徹底的に解剖していく。

—

1. digの出力構造：DNSメッセージの「解剖図」

dig example.com を実行した際、出力されるのは単なる結果ではない。DNSプロトコル（RFC 1035）に基づく、非常に緻密な応答メッセージの構造だ。

;; QUESTION SECTION:
;example.com.           IN  A

;; ANSWER SECTION:
example.com.    3600    IN  A   93.184.216.34

;; AUTHORITY SECTION:
example.com.    172800  IN  NS  a.iana-servers.net.
example.com.    172800  IN  NS  b.iana-servers.net.

;; ADDITIONAL SECTION:
... (関連するIPアドレス情報など)

この4つのセクションには、それぞれ明確な役割がある。

QUESTION SECTION：問いの正体

「何を問い合わせたか」を再確認するセクションだ。ここが間違っていれば、そもそも出発点からズレている。特に、ドメインの末尾にドット（.）があるか、あるいは検索ドメインが勝手に付与されていないかを確認する癖をつけよう。

ANSWER SECTION：真実の回答

ここが一番重要だ。問い合わせに対する「正解」が格納されている。もしここが空なら、ドメインが未登録か、あるいは権威DNSサーバーまで問いが届いていない可能性が高い。

AUTHORITY SECTION：管理者の署名

この回答を「誰が保証しているか」を示す。ここには、ドメインを管理する権威DNSサーバーの NS レコードが並ぶ。トラブル時に「今、誰に聞いているのか？」を特定する際、ここを追うことで、DNSの再帰的な参照フローを逆流できる。

ADDITIONAL SECTION：付録の知恵

ANSWER や AUTHORITY で示されたホスト名のIPアドレスなど、利便性のために付与される情報だ。例えば NS レコードのホスト名が、そのまま同じドメイン内にある場合、ここでIPを教えてくれないと「グルーレコード」の欠如という別のトラブルに繋がる。

—

2. 現場で役立つ実践的デバッグフロー

Web APIの疎通確認や、負荷分散用の CNAME が意図した通りに解決されているか確認する際、僕は以下のコマンドを常習的に叩く。

特定のDNSサーバーを指定して叩く

デフォルトのDNS（ISP等）が汚染されている、あるいはプロパゲーション（浸透）待ちで古い情報を返している時は、権威DNSサーバーを直接指定する。

# @ で直接DNSサーバーを指定する（例: Google Public DNS）
dig @8.8.8.8 example.com A +noall +answer

+noall +answer を付けると、余計なセクションを削ぎ落とし、純粋な回答だけを抽出できる。スクリプトに組み込む際に非常に便利だ。

PythonからDNSを引く（実務コード）

運用自動化ツールを作る際、subprocess で dig を叩くのは悪手だ。Pythonの dnspython ライブラリを使えば、DNSメッセージの各セクションを構造体として取得できる。

import dns.resolver

def check_dns(domain):
    try:
        # クエリを発行
        answers = dns.resolver.resolve(domain, 'A')
        for rdata in answers:
            print(f"IP Address: {rdata.to_text()}")
    except Exception as e:
        # タイムアウトやNXDOMAINなどのエラーをハンドリング
        print(f"Error resolving {domain}: {e}")

# 実行例
check_dns("google.com")

—

3. トラブルシューティングの極意：「+trace」を使いこなせ

もし、dig を打っても一向に解決できない、あるいは挙動がおかしい場合。迷わず +trace オプションを使え。

dig example.com +trace

これは、ルートサーバー（.）からトップレベルドメイン（.com）、そして権威DNSサーバーへと、DNSのルックアップフローを一段ずつ手繰り寄せるコマンドだ。「どこで解決が止まっているか」が手に取るようにわかる。

ルートで止まる場合: 上位ネットワークの経路障害か、DNSサーバーの設定ミス。
権威サーバーで止まる場合: ゾーンファイルの設定ミスか、TTLの設定不備。

—

最後に：ネットワークを「見る」力を養え

DNSのトラブルは、多くの場合「設定の不整合」や「キャッシュの期限切れ」といった、論理的なミスに起因する。dig の出力を眺めることは、パケットの旅路を追体験することと同じだ。

教科書を読み込むのもいいが、まずは本番環境や検証環境で、意識的に dig を叩き、各セクションが何を語りかけているのかを観察してみてほしい。その積み重ねが、いざ大規模障害が起きた時に、誰よりも早く「ここが怪しい」と指させる、君の強固な武器になるはずだ。

さあ、次は君がパケットの行方を追いかける番だ。健闘を祈る。