【入門編】 DNSクエリタイプ(A, AAAA, CNAME, MX, TXT, SOA)のdigによる個別取得 – トラブルシューティング＆ネットワーク運用監視実践ガイド

皆さん、こんにちは！
大規模データセンターの片隅で日夜ネットワークの健全性を見守るNOCシニアエンジニア、そしてこの技術ブログの主筆ライターを務める私です。今日も元気にキーボードを叩いていきましょう！

さて、インフラやネットワークの学習を始めたばかりの皆さん、DNSという言葉を聞くと、どうも頭がこんがらがってしまう……なんて経験、ありませんか？
「名前解決」「ゾーンファイル」「リソースレコード」……カタカナや英語が並ぶと、それだけでアレルギー反応が出ちゃう、なんて方もいるかもしれませんね。

でも、安心してください。
今回は、そんなDNSの世界を、もっと身近な「郵便配達」に例えながら、dig コマンドを使って、まるで探偵のようにピンポイントで情報を引き出す方法を、私の泥臭い現場経験も交えつつ、とことん優しく解説していきます。

特に、Webサイトが見れない、メールが届かないといったトラブルシューティングの現場では、この dig コマンドが本当に頼りになる相棒なんです。一つずつ、じっくりと理解を深めていきましょう！

—

郵便局の住所案内係と「DNS」の世界

まずは、DNSの基本的な仕組みを、私たちが日常で使う「郵便」に例えてざっくりと理解していきましょう。

あなたが誰かに手紙を送りたいとします。でも、知っているのは相手の名前（例えば「技術メディア株式会社」）だけ。住所（「東京都千代田区霞が関1-1-1」）は知らない、という状況を想像してみてください。

こんな時、どうしますか？そう、郵便局の「住所案内係」に尋ねますよね。

「技術メディア株式会社」 ← これがWebサイトでいうところの 「ドメイン名」 です。例えば example.com のようなものですね。
「東京都千代田区霞が関1-1-1」 ← これがコンピューターが理解する 「IPアドレス」 です。例えば 192.0.2.1 や 2001:db8::1 のような数字の羅列ですね。
「郵便局の住所案内係」 ← これがまさに 「DNSサーバー」 の役割なんです。

DNSサーバーは、あなたが「example.com の住所はどこ？」と尋ねると、「192.0.2.1 ですよ」と教えてくれる、インターネットの「住所案内所」のような存在なんですね。

DNSサーバーが持っている「名簿」の中身：リソースレコード

さて、郵便局の住所案内係が持っているのは、ただの住所録ではありません。会社名、住所だけでなく、「メールはどこに送ればいいか」「代表者の連絡先は？」といった、様々な情報が書かれた「名簿」を持っていますよね。

DNSサーバーも同じように、様々な情報を持っています。これをまとめて 「リソースレコード (Resource Record)」 と呼びます。
このリソースレコードには、WebサイトのIPアドレスだけでなく、メールサーバーの情報や、ドメインの管理情報など、色々な種類があるんです。

そして、今回主役となる dig コマンドは、この「名簿」の中から、あなたが「知りたい！」と思う特定の種類の情報だけをピンポイントで引き出すことができる、非常に強力なツールなんです。まるで、名簿の特定の項目だけを指差して「これについて教えて！」と質問するようなもの、と考えてくださいね。

—

dig コマンドってどんな魔法？

dig コマンドは、「Domain Information Groper」の略で、その名の通り、ドメインに関する情報を深く掘り下げて（Groper）取得するためのツールです。

ping や traceroute もネットワーク診断には欠かせませんが、これらは「疎通確認」や「経路確認」が主な目的です。それに対し dig は、まさにDNS、つまり「名前解決」の仕組みが正しく動いているか、特定のドメインがどんな情報を公開しているかを確認するために特化したコマンドなんですね。

基本的な使い方はとってもシンプル。

dig example.com

これで example.com のDNS情報を問い合わせることができます。でもこれだと、example.com に関する「代表的な情報」がまとめて表示されてしまい、本当に知りたい情報がどこにあるのか、慣れないうちはちょっと分かりにくいかもしれません。

そこで今回解説するのが、特定の「リソースレコードタイプ」を指定して、必要な情報だけをスマートに引き出す方法なんです！

—

いよいよ本題！各種DNSクエリタイプを深掘り！

DNSのリソースレコードには、たくさんの種類があります。今回は、特に現場でよく使う、以下の6つのタイプに絞って、その役割と dig コマンドでの使い方、そして結果の読み方を丁寧に見ていきましょう。

1. Aレコード (IPv4アドレス)
2. AAAAレコード (IPv6アドレス)
3. CNAMEレコード (別名)
4. MXレコード (メールサーバー)
5. TXTレコード (テキスト情報)
6. SOAレコード (ドメイン管理情報)

1. Aレコード (Address Record) – 「この会社、番地は何番？」

DNSの世界で最も基本的で、最も頻繁に使われるのが Aレコード です。これは、ドメイン名（Webサイトの名前）が、どの IPv4アドレス に紐付いているかを示すレコードになります。

先ほどの郵便の例で言えば、「技術メディア株式会社の番地は何番？」と聞いて、1-1-1 と教えてもらうようなものです。Webサイトにアクセスするとき、ブラウザはこの Aレコード を使って、WebサーバーのIPアドレスを調べているんですよ。

dig コマンドでの取得方法

dig example.com A

example.com の後に A と指定することで、Aレコードの情報だけを取得できます。

結果の読み方

; <<>> DiG 9.16.1-Ubuntu <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56930
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

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

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

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Jul 23 10:00:00 JST 2024
;; MSG SIZE  rcvd: 47

注目すべきは ;; ANSWER SECTION: の部分です。

example.com.：問い合わせたドメイン名ですね。
86400：これは TTL (Time To Live) と言って、この情報がDNSキャッシュにどれくらいの時間保持されても良いかを示します。単位は秒で、86400 秒は24時間ですね。この値が短いほど、DNSの変更が素早く反映されることになります。
IN：インターネットクラスのレコードであることを示します。
A：これがレコードタイプ、Aレコード であることを示します。
93.184.216.34：これが example.com に紐付けられた IPv4アドレス です！

現場での活用術： Webサイトが見れない時、まず dig example.com A でWebサーバーのIPアドレスが正しいか、変わっていないかを確認します。もし変更されていれば、DNSの伝播がまだ完了していない可能性や、設定ミスが疑われますよね。

2. AAAAレコード (IPv6 Address Record) – 「この会社、IPv6の番地は何番？」

Aレコード がIPv4アドレスを解決するのに対し、AAAAレコード は IPv6アドレス を解決するためのレコードです。読み方は「クアッドエーレコード」や「エーエーエーエーレコード」と呼ぶことが多いですね。

IPv6は、次世代のインターネットプロトコルとして普及が進んでおり、IPv4アドレスが枯渇していく中でその重要性が増しています。IPv6でWebサイトを公開している場合は、この AAAAレコード が設定されています。

dig コマンドでの取得方法

dig example.com AAAA

A の代わりに AAAA を指定するだけです。

結果の読み方

; <<>> DiG 9.16.1-Ubuntu <<>> example.com AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6220
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

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

;; ANSWER SECTION:
example.com.            86400   IN      AAAA    2606:2800:220:1:248:1893:25c8:1946

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Jul 23 10:05:00 JST 2024
;; MSG SIZE  rcvd: 59

;; ANSWER SECTION: に注目。

AAAA：これがレコードタイプ、AAAAレコード であることを示します。
2606:2800:220:1:248:1893:25c8:1946：これが example.com に紐付けられた IPv6アドレス です。IPv4アドレスとは見た目が随分違いますよね。

現場での活用術： IPv6対応のWebサービスをデプロイした際、IPv6でのアクセスがうまくいかない場合に AAAAレコード が正しく設定されているかを確認します。最近は、CDN（コンテンツデリバリーネットワーク）などもIPv6に対応しているので、その確認にも使いますよ。

3. CNAMEレコード (Canonical Name Record) – 「この部署、実はあの部署と同じ場所だよ」

CNAMEレコード は、あるドメイン名が別のドメイン名の 「別名（エイリアス）」 であることを示します。

郵便の例で言えば、「『技術メディア株式会社プレスリリース室』は、実は『技術メディア株式会社広報部』と同じ場所にあるよ」と教えてくれるようなものです。実際に荷物を送るときは「広報部」の住所に送れば良い、ということですね。

Webサイトでよく使われるのは、例えば www.example.com を example.com の別名として設定したり、CDNを使っている場合に、CDNが提供するホスト名に自社ドメインを紐付けたりするケースです。

dig コマンドでの取得方法

dig www.example.com CNAME

www.example.com の CNAME レコードを問い合わせます。

結果の読み方

; <<>> DiG 9.16.1-Ubuntu <<>> www.example.com CNAME
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38283
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.example.com.               IN      CNAME

;; ANSWER SECTION:
www.example.com.        86400   IN      CNAME   example.com.
example.com.            86400   IN      A       93.184.216.34

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Jul 23 10:10:00 JST 2024
;; MSG SIZE  rcvd: 79

;; ANSWER SECTION: を見てください。

www.example.com. 86400 IN CNAME example.com.：
CNAME：これがレコードタイプです。
example.com.：www.example.com の 正規名（Canonical Name） は example.com であることを示しています。つまり、www.example.com にアクセスがあったら、まずは example.com の情報を見てね、ということです。
example.com. 86400 IN A 93.184.216.34：
CNAME レコードは、最終的に Aレコード や AAAAレコード に解決される必要があります。この例では、example.com の Aレコード も同時に表示されていますね。これは dig が親切に、最終的な解決先まで教えてくれているんです。

現場での活用術： Webサイトのサブドメイン（例: blog.example.com）を別のサービス（例: WordPress.comやShopify）で運用していて、そのサービスが提供するホスト名に CNAME で紐付ける、なんてことはよくあります。正しく紐付けられているかの確認に必須です。また、CNAME の設定が循環参照になっていないか（AがBを指し、BがAを指す、といった無限ループ）の確認も重要です。

4. MXレコード (Mail Exchanger Record) – 「メールはどこに届けたらいい？」

MXレコード は、そのドメイン宛のメールが、どのメールサーバー（郵便局でいう「集配所」や「メールボックス」ですね）に配送されるべきかを示すレコードです。

「技術メディア株式会社宛のメールは、△△メールサーバーに送ってください」と教えてくれるのが MXレコード です。これが正しく設定されていないと、メールが届かないという致命的な問題が発生してしまいます。

dig コマンドでの取得方法

dig example.com MX

MX を指定することで、MXレコードの情報だけを取得できます。

結果の読み方

; <<>> DiG 9.16.1-Ubuntu <<>> example.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41808
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
example.com.            3599    IN      MX      0 mx.example.com.

;; ADDITIONAL SECTION:
mx.example.com.         3599    IN      A       93.184.216.34

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Jul 23 10:15:00 JST 2024
;; MSG SIZE  rcvd: 85

;; ANSWER SECTION: に注目。

MX：レコードタイプです。
0：これは 優先度 (Preference) を示します。複数のMXレコードがある場合、数字の小さい方が優先されます。例えば、0 と 10 があれば、0 のメールサーバーがプライマリで、もしダウンした場合に 10 のサーバーにフォールバックする、といった設定が可能です。
mx.example.com.：これが example.com 宛のメールを受け取る メールサーバーのホスト名 です。

;; ADDITIONAL SECTION: には、そのメールサーバーのホスト名 (mx.example.com) の Aレコード （IPアドレス）が記載されていることが多いです。これも dig が親切に、最終的な解決先まで教えてくれています。

現場での活用術： 「メールが送れない」「メールが届かない」というトラブルが発生したら、真っ先に MXレコード を確認します。優先度が正しく設定されているか、指定されたメールサーバーのホスト名が正しいか、そのホスト名がAレコードで正しいIPアドレスに解決されているか、といった点を入念にチェックします。クラウドのメールサービス（Google Workspace, Microsoft 365など）へ移行する際には、このMXレコードの変更が必須になります。

5. TXTレコード (Text Record) – 「この荷物、本物だよ！」「開けちゃダメ！」

TXTレコード は、その名の通り、ドメインに関連する自由なテキスト情報を記述するためのレコードです。一見地味ですが、最近ではその重要性が非常に増しています。

郵便の例で言えば、荷物に貼られた「公式ショップからの発送です」という証明書だったり、「壊れ物注意」といった注意書きだったり、あるいは「この荷物は本人以外開封厳禁」といったセキュリティに関する指示書だったりします。

特にインターネットの世界では、SPF (Sender Policy Framework) や DKIM (DomainKeys Identified Mail)、DMARC (Domain-based Message Authentication, Reporting, and Conformance) といったメール認証の情報を記述するためによく使われます。これらは、メールのなりすましを防ぐための重要なセキュリティ技術なんです。

dig コマンドでの取得方法

dig example.com TXT

TXT を指定して、TXTレコードの情報を取得します。

結果の読み方

; <<>> DiG 9.16.1-Ubuntu <<>> example.com TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1815
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

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

;; ANSWER SECTION:
example.com.            3599    IN      TXT     "v=spf1 -all"

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Jul 23 10:20:00 JST 2024
;; MSG SIZE  rcvd: 57

;; ANSWER SECTION: に注目。

TXT：レコードタイプです。
"v=spf1 -all"：これが テキスト情報 です。この例は SPFレコード の一例で、「このドメイン (example.com) からメールを送ることが許可されているのは、このSPFレコードで定義されたサーバーだけだよ。それ以外のサーバーからのメールは拒否してね」といった意味になります。

現場での活用術： メールが迷惑メールに分類されやすい、送信元を詐称したスパムメールが頻繁に届くといった問題に直面した時、TXTレコード で設定されているSPF、DKIM、DMARCの設定が正しいかを真っ先に確認します。クラウドサービスによっては、ドメインの所有権確認のために、特定の文字列を TXTレコード に追加するよう求められることもありますね。

6. SOAレコード (Start of Authority Record) – 「この名簿、誰が責任者で、いつ更新されたの？」

SOAレコード は、そのドメインのゾーンファイル（DNS情報のまとまり）に関する 「権威（Authority）」、つまり「このドメインの情報の管理者情報」を示すレコードです。

郵便の例で言えば、「このエリアの住所名簿は、○○郵便局の△△さんが管理していて、最後に更新したのは▲月▲日だよ。定期的に内容を確認してね」といった、名簿自体の管理情報 を示しているようなものです。

DNSサーバーがこのドメインの情報を信頼して良いか、どれくらいの頻度で更新を確認すべきかといった、ゾーンファイル全体の振る舞いを定義する、非常に重要なレコードです。

dig コマンドでの取得方法

dig example.com SOA

SOA を指定して、SOAレコードの情報を取得します。

結果の読み方

; <<>> DiG 9.16.1-Ubuntu <<>> example.com SOA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53139
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

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

;; ANSWER SECTION:
example.com.            3599    IN      SOA     ns.example.com. hostmaster.example.com. 1994042801 7200 3600 1209600 3600

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Jul 23 10:25:00 JST 2024
;; MSG SIZE  rcvd: 83

;; ANSWER SECTION: に注目。ここには複数のフィールドが並んでいます。

SOA：レコードタイプです。
ns.example.com.：プライマリネームサーバー (MNAME) 。このゾーンファイルを管理する「主」となるDNSサーバーのホスト名です。
hostmaster.example.com.：管理者メールアドレス (RNAME) 。ゾーンファイルの管理者のメールアドレスです。（@ではなく.で区切られているのが特徴です。hostmaster@example.com と読み替えてください）
1994042801：シリアル番号 (SERIAL) 。ゾーンファイルのバージョン番号です。この番号が変更されると、セカンダリDNSサーバーが新しい情報をプライマリから取得しに行きます。通常は日付と連番で管理されます。
7200：リフレッシュ間隔 (REFRESH) 。セカンダリDNSサーバーが、プライマリDNSサーバーにゾーンファイルの更新がないか確認しに行く間隔です。（秒単位、この例では2時間）
3600：リトライ間隔 (RETRY) 。リフレッシュに失敗した場合に、再試行するまでの間隔です。（秒単位、この例では1時間）
1209600：有効期限 (EXPIRE) 。セカンダリDNSサーバーが、プライマリDNSサーバーから情報を取得できない場合に、いつまでその情報を有効とみなすかという期限です。（秒単位、この例では2週間）この期間を過ぎると、セカンダリはゾーンファイルの情報が無効と判断し、クエリに応答しなくなります。
3600：最小TTL (MINIMUM TTL) 。このゾーン内のレコードに明示的なTTLが設定されていない場合のデフォルト値、またはネガティブキャッシュ（存在しないドメインの情報をキャッシュする期間）のTTLとして使われます。（秒単位、この例では1時間）

現場での活用術： 新しいドメインを設定した時や、DNSサーバーを移行した時など、ゾーンファイル全体の管理状況を確認するのに使います。特に、シリアル番号 が更新されているか、リフレッシュ間隔 や 有効期限 が適切に設定されているかは、DNSの伝播速度や安定性に直結するため、非常に重要です。DNSトラブルで「キャッシュに古い情報が残っている！」なんて時に、この辺りの設定を疑うこともありますよ。

—

なぜ個別クエリが必要なの？現場での活用術まとめ

ここまで、様々なレコードタイプを個別に dig コマンドで取得する方法を見てきました。
「dig example.com だけで全部見れるなら、それでいいんじゃないの？」と思う方もいるかもしれません。しかし、現場では個別クエリが非常に役立つ場面がたくさんあるんです。

1. 特定の情報に焦点を当てる

dig だけだと、ずらっと情報が表示されてしまい、どこに何があるか見落としがちです。特に初学者の方にとっては、情報が多すぎて混乱することもありますよね。
個別クエリなら、知りたい情報だけがシンプルに表示されるため、確認がはるかに効率的になります。

2. 設定変更の正確な確認

「WebサイトのIPアドレスを変更した」「メールサーバーを移行した」といった場合、その変更がDNSに正しく反映されたかを確認する際に、dig example.com A や dig example.com MX といった形でピンポイントに確認できます。
これにより、変更が意図通りに行われたかを素早く、かつ確実に検証できます。

3. トラブルシューティングの効率化

「Webサイトが見れない」なら A や AAAA。
「メールが届かない」なら MX や TXT (SPF/DKIM)。
「サブドメインがおかしい」なら CNAME。
このように、問題の種類によって確認すべきレコードタイプが絞られるため、効率的に原因を特定するための第一歩となります。

4. キャッシュの影響を受けずに最新情報を確認

dig コマンドは、デフォルトではルートヒントや権威サーバーから情報を引き直すため、ローカルDNSサーバーのキャッシュに依存しない、最新の情報を取得しやすいというメリットもあります（ただし、明示的に特定のDNSサーバーを指定することも可能です）。

—

まとめ：dig はあなたの頼れる相棒！

いかがでしたでしょうか？
DNSの各リソースレコードタイプと、それを dig コマンドでピンポイントに取得する方法、そしてその結果の読み方について、郵便配達の例を交えながら解説してきました。

最初は少し難しく感じるかもしれませんが、これらのコマンドは、Webサイトの公開、メールサービスの運用、そして日々のトラブルシューティングにおいて、まさに「百戦錬磨のNOCエンジニアの右腕」とも言える非常に強力なツールなんです。

実際に手を動かして、色々なドメインに対して dig コマンドを試してみてください。
google.com や facebook.com など、皆さんがよく知るドメインのDNS情報がどうなっているのかを調べてみるのも面白いですよ。

きっと、インターネットの裏側でどんな情報がやり取りされているのか、そのリアルな挙動を肌で感じることができるはずです。

今回の内容が、皆さんのインフラ・ネットワーク学習の一助となれば幸いです。
それでは、また次回の記事でお会いしましょう！これからも一歩ずつ、着実にスキルアップしていきましょうね！