DNSの深淵を覗く：digが暴くパケットの真実とセクション別出力構造の読み方
NOCの深夜シフト、けたたましいアラート音とともにSlackが跳ねる。「APIの名前解決が時々タイムアウトしています」「特定のリージョンからDBエンドポイントへ到達できません」。この手のトラブルシューティングにおいて、見習いエンジニアが最初にやることは、大抵ブラウザを開いてリロードするか、気休めの ping を打つことだ。しかし、百戦錬磨のインフラエンジニアが真っ直ぐに手を伸ばすのは、ターミナルであり、そして dig コマンドだ。
DNSは、インターネットという巨大な神経網のシナプスである。ここが詰まれば、いかにL3ルーティングが美しかろうが、BGPの経路が最適化されていようが、アプリケーション層では完全な沈黙が訪れる。そして、そのDNS応答メッセージの深部を最も生々しく、最も正確に我々に見せてくれるのが dig （Domain Information Groper）にほかならない。
本稿では、dig コマンドの基本構文を再確認するとともに、DNSパケットがUDP/TCPのペイロードとしてどのように構築され、応答メッセージの4つのセクション（QUESTION、ANSWER、AUTHORITY、ADDITIONAL）が何を意味するのかを、パケットレベルの挙動とカーネルのネットワークスタックの視点を交えて徹底的に紐解いていく。
—
1. dig の基本構文と、DNSクエリのトランスポート層におけるリアルな挙動
まずは、日々の運用で指が覚えているべき基本構文から入ろう。単に dig example.com と叩くだけでも情報は得られるが、プロフェッショナルはオプションを駆使してDNSサーバーの挙動を剥き出しにする。
# 基本的なAレコードの問い合わせ（デフォルトはフルスタブリゾルバではなく、OSの/etc/resolv.confを参照）
dig example.com A
# 特定の権威DNSサーバー（例: 8.8.8.8）に対して再帰問い合わせを無効（+norecurse）にして直撃する
dig @8.8.8.8 example.com A +norecurse
# トランスポート層を強制的にTCPにする（UDPパケットの断片化やEDNS0のサイズ制限を超える巨大な応答を検証する場合）
dig example.com A +tcpここでインフラエンジニアとして意識しなければならないのは、DNSがデフォルトではUDP（ポート53）でパケットを飛ばしているという事実だ。UDPはコネレスであり、ハンドシェイクのオーバヘッドがない一方で、信頼性がない。DNSメッセージが通常サイズとされる512バイト（EDNS0未使用時）を超える場合、あるいはゾーン転送などの巨大なペイロードを扱う場合、パケットは断片化（Fragmentation）のリスクに晒される。
現代のインターネットでは、IPv4のフラグメントはルーターでの処理負荷が高く、セキュリティ上の脆弱性（DNSキャッシュポイズニングのベクトル等）や、ファイアウォール（FW）での破棄対象になりやすい。そのため、+tcp オプションを用いたTCPフォールバックや、EDNS0（Extension Mechanisms for DNS）によるバッファサイズ拡張（通常4096バイト程度）の挙動を dig で正確に追跡することが、可用性の高いアーキテクチャ設計には不可欠となる。
—
2. dig 出力の全貌：4つのセクションを解剖する
実際に dig を実行した際に出力されるテキストを、上から順にではなく、DNSメッセージのパケット構造に沿って分解してみよう。出力は大きく分けて、ヘッダー情報、QUESTION、ANSWER、AUTHORITY、ADDITIONAL、そして統計情報の6つのブロックで構成されている。
以下のコマンドを実行したと仮定する。
dig @1.1.1.1 example.com A返される出力の各セクションについて、パケットのバイナリ構造と対応させながら深掘りする。
; <<>> DiG 9.16.1-Ubuntu <<>> @1.1.1.1 example.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34521
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS version: 0, flags:; udp: 1232কবি
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 300 IN A 93.184.216.34
;; AUTHORITY SECTION:
(なし)
;; ADDITIONAL SECTION:
(EDNS0擬似セクションが含まれる場合ここに出現)
;; Query time: 12 msec
;; SERVER: 1.1.1.1#53(53000)
;; LATENCY / 0.15ms① HEADER セクションと フラグの読み方
->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34521 の行だ。
- opcode: 通常の問い合わせである
QUERYが設定されている。 - status: 応答の状態コード。
NOERRORは正常終了を意味する。ここがNXDOMAIN（ドキュメントが存在しない）やSERVFAIL（権威サーバーの障害や設定ミス）になっている場合、上位のルーティングやゾーン設定に異常がある。 - id: 16ビットのトランザクションID。クライアントはこのIDを見て、どのリクエストに対するレスポンスかを一致させる。これが予測可能な場合、DNSスプーフィングの温床となる。
- flags:
qr rd ra adの意味を瞬時に理解できなければならない。 qr(Query Response): これが応答パケットであることを示す。rd(Recursion Desired): クライアントが再帰的解決を要求した。ra(Recursion Available): 問い合わせ先のDNSサーバーが再帰的解決をサポートしている。ad(Authenticated Data): DNSSEC検証が正常に行われたことを示す。セキュリティを重視する環境では、このフラグが立っているかを確認することが極めて重要だ。
② QUESTION セクション
;; QUESTION SECTION:
;example.com. IN Aこれは、クライアントが「何を投げたか」の鏡写しだ。左から順に「問い合わせたドメイン名 (example.com.)」、「クラス (IN = Internet)」、「タイプ (A = IPv4アドレス)」を表す。ここが意図したクエリになっているかをまず確認する。ドット（root）で終わる完全修飾ドメイン名（FQDN）の形式になっていることに注目してほしい。
③ ANSWER セクション（実データの核心）
;; ANSWER SECTION:
example.com. 300 IN A 93.184.216.34ここが名前解決の成果物である。
300: TTL（Time To Live）。秒単位。このレコードがローカルリゾルバやOSのキャッシュにどれだけ留まるかを示す。インフラ設計において、このTTLのチューニングは極めてデリケートだ。障害時のフェイルオーバーを迅速に行いたい場合は低く（例: 60秒以下）設定し、DNSサーバーへの負荷軽減やレイテンシ最適化を優先するなら高く（例: 3600秒以上）設定する。ただし、低すぎるTTLは、大規模トラフィック時におけるDNSインフラへのDDoSライクな負荷増大を招くため注意が必要だ。IN A: クラスとレコードタイプ。93.184.216.34: 解決されたIPアドレス。
④ AUTHORITY セクション
このセクションには、「どのネームサーバーがこのゾーンの権威（Authoritative）を持っているか」の情報が格納される。通常の A レコードの問い合わせでは空欄になることが多いが、NS レコードを引いた場合や、キャッシュDNSサーバーが権威サーバーからデータを引く際の参照情報として極めて重要な役割を果たす。
例えば、ドメインの委任（Delegation）が正しく行われているかを検証する際、この権威セクションにどのNSがリストされているかを確認することで、迷子のDNSパケット（ラメレーション）の所在を特定できる。
⑤ ADDITIONAL セクション と EDNS0
現代のDNSにおいて無視できないのが、このADDITIONALセクションに含まれる OPT PSEUDOSECTION（EDNS0） だ。
;; OPT PSEUDOSECTION:
; EDNS version: 0, flags:; udp: 1232古典的なDNSメッセージはUDPペイロードが512バイトに制限されていたため、DNSSECの署名鍵や大量のレコードを含む応答が入りきらず、強制的にTCPフォールバックが発生してパフォーマンスが劣化していた。これを解決するのがEDNS0であり、udp: 1232 のように、クライアント側が「我が方は1232バイトまでのUDPパケットを受け入れ可能です」と宣言するための拡張領域がここに挿入される。
（※1232バイトという数字は、IPv6の最小MTUである1280バイトから、IPv6ヘッダー（40バイト）とUDPヘッダー（8バイト）の安全マージンを引いた値であり、パケットの断片化を確実に回避するための黄金律として現代のインフラでは広く採用されている）
—
3. 実務で役立つ dig の高度な活用テクニックとパフォーマンス最適化
単に名前解決ができるかを確認するだけでなく、プロフェッショナルは dig を使ってネットワークの健康状態を診断する。
トレーサー回路としてのDNS：+trace
DNSの再帰解決のプロセス（Root -> TLD -> Authoritative）をすべて自らの手でトレースしたい場合、以下のコマンドが絶大な威力を発揮する。
dig example.com +traceこのコマンドを実行すると、まずRootサーバー群（a.root-servers.net 等）に直接問い合わせに行き、そこから返されたAUTHORITY/ADDITIONAL情報を基に、次はTLD（.com）の権威サーバーへ、そして最終的なドメインの権威サーバーへと、パケットがステップバイステップでどのような経路を辿って名前解決を完結させるかをすべて出力してくれる。
社内DNSフォワーダーの誤設定や、特定のTLDゾーンにおける遅延（レイテンシ）の原因を突き止めるための必須の武器である。
パフォーマンス測定の自動化とスクリプト連携
CI/CDパイプラインや監視エージェントからDNSの応答速度を計測する場合、+noall +answer などの表示制御オプションを組み合わせることで、純粋な値だけを抽出できる。
# 余計なメタデータを削ぎ落とし、ANSWERセクションのみをクリーンに出力する
dig +noall +answer example.com Aさらに、Bashと組み合わせることで、世界中のパブリックDNSに対する応答速度（RTT）の比較検証も一瞬で行える。
for dns in 1.1.1.1 8.8.8.8 9.9.9.9; do
echo -n "DNS Server: $dns -> "
dig @$dns example.com A +noall +answer | awk '{print "TTL: "$2 " IP: "$NF}'
# クエリにかかった時間を測定する簡易ベンチマーク
time dig @$dns example.com A > /dev/null
done—
4. セキュリティとDNSトランスポートの未来（DoH / DoT）
ここまで dig を用いて平文のUDP/TCP 53番ポートの挙動を解説してきたが、現代のセキュリティ要件において、平文のDNSは「盗聴され放題の通信」である。社内ネットワークであっても、パケットキャプチャを行えば、ユーザーがどのSaaSや社内システムにアクセスしているのかが丸見えになる。
このプライバシーの懸念を解決するのが、DoT（DNS over TLS, ポート853） や DoH（DNS over HTTPS, ポート443） である。
残念ながら、伝統的な dig コマンドの古くからの実装では直接DoHのHTTPSリクエストを投げることは苦手とする場合があるが（※近年のバージョンでは +https や +tls オプションのサポートが進んでいる）、システム背後で稼働するスタブリゾルバ（systemd-resolved や Unbound）の挙動を検証する際には、依然として dig が最強のデバッグツールであることに変わりはない。
セキュアなDNS通信では、TLSハンドシェイク（TLS 1.3）のオーバーヘッドや、HTTP/2・HTTP/3のストリーム多重化が絡むため、レイテンシの振る舞いが従来のUDP 53とは大きく異なる。しかし、どれほどプロトコルが進化しようとも、アプリケーション層が受け取る「DNSメッセージの構造（HEADER, QUESTION, ANSWER, AUTHORITY, ADDITIONAL）」そのものが変わるわけではない。
—
結びにかえて
障害現場において、焦燥感に駆られながら打つコマンドの一撃目は、往々にしてそのエンジニアの「解像度」を映し出す。
単に「名前解決ができません」とエスカレーションするのと、「dig で確認したところ、ルートからの再帰解決の途中で特定の権威サーバーから SERVFAIL が返ってきており、EDNS0のバッファサイズ調整に起因するパケットドロップの可能性が高いです」と報告するのとでは、チームの信頼も、障害解決までのリードタイムも天と地ほどの差が生まれる。
パケットのヘッダーを読み解き、セクションの隅々に隠されたフラグやTTLの意味を論理的に繋ぎ合わせる。その職人芸的なアプローチこそが、複雑怪奇に絡み合うモダンなクラウド・インフラニケーションの海を泳ぎ切るための、最も確実なコンパスなのだ。さあ、ターミナルを開こう。次のパケットが君を待っている。
コメント