【入門編】 digコマンドを用いた詳細なDNSメッセージヘッダーとフラグの解析 – トラブルシューティング＆ネットワーク運用監視実践ガイド

皆さん、こんにちは！ネットワークの深淵を覗き、パケットの流れを日夜追いかけているNOCシニアエンジニアの○○（NOCシニアエンジニアの名前を想像してください）です！

今回は、私たちのデジタルライフを支える「縁の下の力持ち」、DNS（Domain Name System）の世界へ、皆さんと一緒に少しだけ深く潜り込んでみたいと思います。

「DNSなんて、普段意識しないし、なんか難しそう…」

そう思われた方も、ご安心ください！今回は、皆さんがネットワークのトラブルシューティングや運用監視を始めたばかりの「インフラやネットワーク初心者」の方でも、楽しく、そして「なるほど！」と膝を打つような内容でお届けします。

テーマは、dig コマンドを使って、DNSメッセージのヘッダーやフラグを解析すること。特に、AA や TC、RD、RA といった、まるで暗号のような記号たちが何を意味しているのか、そして EDNS0 というオプションがどんな役割を果たしているのかを、身近な例えを交えながら、優しく紐解いていきましょう！

dig コマンドは、DNSの世界における「高性能なX線写真」のようなもの。これを使えば、普段は見えないDNSのやり取りの裏側が、手に取るように分かります。さあ、一緒にDNSの「心臓部」を覗きに行きましょう！

—

1. DNSってそもそも何だっけ？「インターネットの住所録」を再確認！

まずは基本中の基本から。DNSが何をしているのか、改めて確認しておきましょう。

皆さんがWebブラウザで「example.com」と入力してサイトにアクセスする時、コンピューターはまず「example.comって、どこのサーバーに置いてあるんだ？」と疑問に思いますよね。人間は「example.com」という分かりやすい名前で覚えますが、コンピューターは「192.0.2.1」のような数字の羅列、つまりIPアドレスでしかサーバーの場所を特定できません。

ここで登場するのがDNSです！

DNSは、人間にとって分かりやすい「ドメイン名（example.com）」と、コンピューターが理解できる「IPアドレス（192.0.2.1）」を結びつける、いわば「インターネットの住所録」のような役割を果たしています。皆さんのスマホの電話帳と一緒ですね。

普段、皆さんが意識しなくても、このDNSが裏側でサッと働いてくれるおかげで、私たちは「example.com」と打つだけで、目的のWebサイトにたどり着けるわけです。ありがたいですよね！

2. dig コマンドの基本の「き」：DNSに「ちょっと教えて！」と尋ねてみよう

DNSの重要性が分かったところで、いよいよ主役の dig コマンドの登場です！

dig は「Domain Information Groper」の略で、DNSサーバーに直接問い合わせを行い、その応答を詳細に表示してくれるツールです。まずは、試しに皆さんのPCで叩いてみましょう。

dig example.com

実行すると、たくさんの情報が出てきて、ちょっとびっくりするかもしれませんね。でも大丈夫。今は全体像を眺めるだけでOKです。

出力結果の中から、特に注目してほしいのが、以下のセクションです。

;; HEADER <<>> opcode: QUERY, status: NOERROR, id: ...
;; QUESTION SECTION:
;; ANSWER SECTION:

これらはそれぞれ、皆さんがDNSサーバーに「どんな質問をしたか（QUERY）」、DNSサーバーが「どんな答えを返してくれたか（ANSWER）」、そしてその「やり取りの詳細情報（HEADER）」を表しています。まるで、郵便物の「宛名」と「中身」、そして「封筒の情報」を見ているようなイメージですね！

今回は、この「封筒の情報」である HEADER セクションに焦点を当てていきます。特に ;; flags: の行に注目してください。ここには、DNSのやり取りにおける重要な「印（スタンプ）」がたくさん押されているんですよ！

3. DNSメッセージヘッダーって何？「郵便物の封筒」を覗いてみよう！

DNSの応答は、まるで郵便物のようなものだと先ほど例えました。その郵便物の「封筒」にあたるのが、DNSメッセージヘッダーです。この封筒には、郵便物がどこから来て、どこへ行くのか、どんな種類の郵便物なのか、そして特別な処理が必要か、といった情報が詰まっています。

dig コマンドの出力でいうと、以下の部分です。

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

このうち、flags: の後に続く qr rd ra といった部分が、今回注目する「フラグ」です。これらは、郵便物の封筒に押された「特別なスタンプ」だと思ってください。このスタンプを見ることで、そのDNSのやり取りがどんな性質のものだったのか、たくさんのヒントが得られるんです。

それぞれのスタンプが何を意味するのか、一つずつ見ていきましょう！

—

フラグその1: AA (Authoritative Answer) – 「この情報は公式発表ですよ！」

意味: この応答は、権威DNSサーバー（そのドメインの情報を正式に管理しているサーバー）から直接提供された情報ですよ、という印です。
郵便物の例え: 「この住所録は、役場が発行した公式なものです！」という保証のスタンプ。

通常、皆さんのPCがDNS情報を問い合わせる時、多くの場合、まずプロバイダなどが提供するキャッシュDNSサーバー（地域に設置された「情報のコピーを保管しておく倉庫」みたいなサーバー）に質問します。キャッシュDNSサーバーは、もし自分が過去に問い合わせた情報を持っていれば、それを教えてくれます。この場合、AA フラグは立ちません。

しかし、もしキャッシュDNSサーバーが情報を持っていなかったり、皆さんが直接権威DNSサーバーに問い合わせた場合、その応答には AA フラグが付きます。これは、「私はこのドメインの公式な管理者なので、私の情報が正解ですよ！」と自信を持って宣言しているようなものです。

dig で AA フラグを確認する

権威DNSサーバーに直接問い合わせるには、@ オプションを使います。まずは example.com の権威DNSサーバーを調べましょう。

# example.com のNSレコード（ネームサーバー）を問い合わせる
dig example.com NS +short

出力されたネームサーバーのどれか一つ（例: a.iana-servers.net.）を使って、再度 dig コマンドを実行します。

dig @a.iana-servers.net example.com

# 実行結果（一部抜粋）
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62411
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
                               ^^ ここに `aa` がありますね！

ほら、「aa」というスタンプが押されていますよね！これは、あなたが直接「公式の住所録」を持っているサーバーに問い合わせたから、その公式な情報が返ってきた証拠なんです。トラブルシューティングでは、「正しい情報源から得られた情報かどうか」を確認するために、この AA フラグが非常に役立ちます。

—

フラグその2: TC (TrunCated) – 「情報が多すぎて入りきらなかった！」

意味: DNSの応答メッセージが、UDPプロトコルのサイズ制限（通常512バイト）を超過したため、途中で切り捨てられてしまった、という印です。
郵便物の例え: 「手紙が長すぎて、封筒に入りきらなかったので、途中までしか送れませんでした！」というお知らせ。

DNSの問い合わせは、通常UDPというプロトコルを使います。UDPは高速ですが、一度に送れるデータ量に制限があります。特にDNSSEC（DNSのセキュリティ拡張）を使っている場合や、非常に多くの情報を含む応答の場合、512バイトの制限を超えてしまうことがあります。

TC フラグが立つと、DNSサーバーは「残りの情報はTCPで問い合わせてくださいね」というメッセージを暗に含んでいます。実際には、DNSクライアント（皆さんのOSなど）が賢いので、TC フラグを受け取ると自動的にTCPを使って再問い合わせを行うことが多いです。

TC フラグを確認する

TC フラグが立つのは稀ですが、巨大なDNSレコードを持つドメインや、DNSSECが有効なドメインで発生することがあります。例えば、DNSSECのRRSIGレコードなどを問い合わせると、意図的に TC フラグを発生させることができます。（ちょっと上級編ですね）

# 例えば、DNSSECが有効なドメインでRRSIGレコードを問い合わせる
# この例ではTCフラグは立たないかもしれませんが、巨大な応答を想定
dig example.com RRSIG

もし出力結果に tc が見えたら、「ああ、情報量が多すぎてUDPでは運びきれなかったんだな」と理解してください。

—

フラグその3: RD (Recursion Desired) – 「お願い！探しに行ってきて！」

意味: 問い合わせ元（皆さんのPCなど）が、DNSサーバーに対して「もし知らない情報だったら、代わりに探してきてください」と要求している、という印です。
郵便物の例え: 「この手紙、宛先が不明だったら、あなたが頑張って探し出して届けてね！」という特別な依頼状。

皆さんが普段 dig example.com とコマンドを打つ時、この RD フラグはデフォルトで有効になっています。つまり、皆さんのPCは「もしこのDNSサーバーが example.com のIPアドレスを知らなかったら、根気強く探してきてね！」とお願いしているわけです。

DNSサーバーがこの RD 要求に応えられる場合、そのサーバーは再帰問い合わせ（Recursive Query）が可能なサーバー、つまり「電話帳の情報を代わりに探しに行ってくれる親切な人」ということになります。

dig で RD フラグの有無を制御する

+norecurse オプションを使うと、この RD フラグを立てずに問い合わせることができます。

# RDフラグを立てずに問い合わせる（+norecurse）
dig example.com +norecurse

# 実行結果（一部抜粋）
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36728
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
             ^^ `rd` が消えましたね！

この場合、問い合わせたDNSサーバーが example.com の情報をすぐに持っていなければ、「知らないよ」と答えるか、あるいは「このドメインのことは、この権威DNSサーバーに聞いてみてね」と、次に問い合わせるべきサーバーの情報を教えてくれるだけになります。自分で探しには行ってくれないわけです。

—

フラグその4: RA (Recursion Available) – 「お任せください！私が探しに行ってきます！」

意味: 応答元のDNSサーバーが、再帰問い合わせ（Recursion）の機能を提供していますよ、という印です。
郵便物の例え: 「はい、承知いたしました！宛先が不明でも、私が責任を持って探し出して配達します！」という、郵便局からの頼もしい返事。

これは RD フラグとセットで理解すると分かりやすいです。皆さんが RD フラグを立てて「探してきて！」とお願いした時、DNSサーバーが RA フラグを立てて応答してきたら、「OK！私が探しに行ってくるよ！」と、その依頼を引き受けてくれた証拠です。

ほとんどのキャッシュDNSサーバー（プロバイダが提供するものなど）は、この RA フラグを立てて応答してくれます。

dig で RA フラグを確認する

dig example.com のように、デフォルトのオプションで問い合わせると、通常 RD と RA の両方のフラグが立ちます。

# デフォルト（+recurse が指定されているのと同じ）
dig example.com

# 実行結果（一部抜粋）
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50411
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
             ^^ ^^ `rd` と `ra` が両方ありますね！

もし、皆さんが問い合わせたDNSサーバーが RA フラグを立てずに応答してきたら、それは「ごめん、私は再帰問い合わせの機能は提供していないんだ。自分で権威DNSサーバーを探して問い合わせてみてくれ」と言っているようなものです。これは、意図的に設定されている場合もありますが、DNSサーバーの設定ミスや、オープンリゾルバ対策などで制限されている場合もあります。

—

4. EDNS0 って何？「もっと情報が欲しい！特別な依頼書」

最後に、ヘッダーフラグとは少し異なりますが、dig コマンドの出力によく登場する重要なオプション、「EDNS0」について触れておきましょう。

EDNS0 は「Extension Mechanisms for DNS version 0」の略で、DNSプロトコルを拡張するための仕組みです。先ほど TC フラグのところで触れたように、従来のDNSはUDPの512バイト制限がありましたが、DNSSECの普及や、クライアントのIPアドレス情報をサーバーに伝えるCDN（Content Delivery Network）のニーズなど、より多くの情報をやり取りしたい場面が増えてきました。

EDNS0 は、このサイズ制限を拡張したり、追加の情報を付与したりするための「特別な依頼書」のようなものです。

郵便物の例え: 「この郵便物、通常より大きい荷物なんですけど、特別便で送れますか？」「あと、送り主の細かい情報も一緒に添えておきますね！」といった、特別な処理や情報の追加を依頼するための付箋。

dig コマンドでは、+edns=0 または +bufsize オプションで EDNS0 の利用を明示できます。多くのDNSクライアントはデフォルトで EDNS0 を使用しています。

dig example.com +edns=0

# または、受信バッファサイズを指定
dig example.com +bufsize=4096

出力結果の最後に、以下のようなセクションが見つかるはずです。

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232

この OPT PSEUDOSECTION が EDNS0 の情報です。

version: 0: EDNS のバージョンです（現在は 0 が主流）。
flags: do: DNSSECで署名された応答を要求する DO (DNSSEC OK) フラグなどが入ることがあります。
udp: 1232: クライアントが受け取れるUDPメッセージの最大サイズ（受信バッファサイズ）を示します。これは512バイトよりも大きい値が設定されているのが普通です。

EDNS0 は、現代のDNSインフラにおいて非常に重要な役割を担っています。特にDNSSECの運用や、CDNによる最適化など、パフォーマンスやセキュリティに関わる場面で、このオプションが正しく機能しているかを確認することは、NOCエンジニアにとって必須のスキルになりますね。

—

5. 実践！dig コマンドでDNSフラグを解析してみよう！

さあ、これまで学んだ知識を総動員して、実際にコマンドを叩き、DNSの動きを観察してみましょう！

シナリオ1: キャッシュDNSサーバーへの問い合わせ（デフォルト動作）

まずは、最も一般的な問い合わせ方です。皆さんのPCが参照しているDNSサーバー（通常はプロバイダのDNSサーバーやルーターが配布するDNSサーバー）に対して問い合わせを行います。

# 自分のPCが参照するDNSサーバーに問い合わせる
dig example.com

# 出力例 (flags部分に注目)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36728
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

qr: Query/Response の Response であることを示します。
rd: Recursion Desired。皆さんのPCが「探しに行ってきて！」と要求した印。
ra: Recursion Available。問い合わせたDNSサーバーが「OK、探しに行くよ！」と応じた印。
aa: Authoritative Answer がありませんね。これは、この応答がキャッシュDNSサーバーから返された、つまり「公式の住所録」ではなく、「過去に調べたコピー」から返された情報であることを示しています。

シナリオ2: 権威DNSサーバーへの直接問い合わせ

次に、example.com の公式な情報を管理している権威DNSサーバーに直接問い合わせてみましょう。

# 1. example.com のNSレコードを調べて、権威DNSサーバーのアドレスを確認
# この例では a.iana-servers.net. が見つかったと仮定
dig example.com NS +short

# 2. その権威DNSサーバーに直接問い合わせる
dig @a.iana-servers.net example.com

# 出力例 (flags部分に注目)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62411
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

qr, rd, ra: シナリオ1と同じ意味です。
aa: Authoritative Answer がありますね！これは、公式の住所録を持っているサーバーから直接返された、信頼できる情報であることを示しています。トラブルシューティングで「この情報、本当に正しいの？」と疑問に思った時は、このように権威DNSサーバーに直接確認し、aa フラグの有無を見るのが鉄則です！

シナリオ3: 再帰問い合わせをしない設定で権威DNSサーバーに問い合わせる

最後に、+norecurse オプションを使って、「探しに行かないで、知ってることだけ教えて」と依頼してみましょう。権威DNSサーバーは通常、再帰問い合わせ機能を提供していないため、この設定で問い合わせると面白い結果になります。

# 権威DNSサーバーに「探しに行かないで」と問い合わせる
dig @a.iana-servers.net example.com +norecurse

# 出力例 (flags部分に注目)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

qr, aa: シナリオ2と同じ意味です。
rd: Recursion Desired が消えていますね！これは、皆さんが +norecurse オプションを使ったため、「探しに行って！」という要求をDNSサーバーに送らなかったからです。
ra: Recursion Available も消えています！権威DNSサーバーは通常、再帰問い合わせ機能を提供しないため、たとえ rd を送ったとしても ra は返ってこないことが多いです。しかし、この例では rd を送っていないので、ra も当然返ってきません。

このように、dig コマンドのオプションを少し変えるだけで、DNSサーバーとのやり取りの性質がガラッと変わるのが分かりますね！

—

6. まとめ：「見えない郵便物」のスタンプを読み解くNOCの目！

今回は、dig コマンドを使ってDNSメッセージヘッダーの奥深い世界、特にAA、TC、RD、RA といったフラグや EDNS0 の役割について、郵便物の例えを交えながら、優しく解説してきました。

最初は「何だか小難しい記号だな…」と感じたかもしれませんが、それぞれのフラグが「公式発表だよ！」「情報が多すぎて入りきらなかった！」「探しに行ってきて！」「お任せください！」といった、人間味あふれるメッセージを含んでいることが分かったのではないでしょうか。

NOCエンジニアとして、私たちは日々、ネットワークの「見えない郵便物」のやり取りを監視し、トラブルが発生すれば、この「郵便物の封筒に押されたスタンプ」を読み解くことで、何が起こっているのか、どこに問題があるのかを迅速に特定します。

dig コマンドは、そのための強力なツールの一つです。今回学んだフラグの意味を理解していれば、DNS関連のトラブルが発生した際に、より深く、より正確に原因を特定できるようになるはずです。

ネットワークの世界は奥深く、覚えることも多いですが、一つ一つの知識が繋がっていくと、まるでパズルが完成していくような楽しさがあります。

これからも、皆さんがネットワークの面白さに触れ、一歩ずつ成長していけるような記事を書いていきたいと思います。

それでは、また次回の記事でお会いしましょう！ネットワークの旅を、楽しみながら続けていきましょうね！