DNSクエリログについて

Webサイトの表示、メールの送受信、アプリの通信など、私たちが普段使っている多くのインターネット通信は、最初にDNSの名前解決から始まります。

そのDNSの動きを記録したものが、DNSクエリログです。

「名前は聞いたことがあるけれど、何が記録されているのかわからない」「セキュリティや障害調査で重要と聞くけれど、実際にどう役立つのかイメージしにくい」このように感じている方も多いのではないでしょうか。

この記事では、DNSクエリログの基本から、ログに記録される内容、活用シーン、注意点まで、できるだけわかりやすく整理して解説します。

DNSクエリログとは何か

DNSクエリログとは、DNSサーバーやDNSリゾルバに対して行われた問い合わせと、その処理結果を記録したログのことです。

簡単に言えば、「いつ、どこから、どの名前に対してDNS問い合わせが行われ、どう応答されたかを残した記録」だと考えるとわかりやすいでしょう。

DNSは「ドメイン名をIPアドレスに変換する仕組み」と説明されることが多いですが、実際にはそれだけではありません

Webサイト接続に使うAレコードやAAAAレコードだけでなく、メール配送先を示すMXレコード、認証や確認に使われるTXTレコード、別名を示すCNAMEレコードなど、さまざまな情報を扱います。

DNSクエリログには、こうした名前解決の履歴が残るため、どの端末やシステムが、どの名前を解決しようとしたのかを確認することができます。

なぜDNSクエリログが重要なのか

DNSクエリログが重要とされる理由は、通信のかなり早い段階を観測できるからです。

ユーザーがWebサイトを開くとき、アプリが外部APIへ接続するとき、メールサーバーが配送先を確認するときなど、多くの通信では最初にDNS問い合わせが行われます。

そのためDNSクエリログを見ると、実際の通信内容そのものではなくても、通信の入口で何が起きていたかを把握しやすくなります。

この性質から、DNSクエリログは主に次のような場面で活用されます。

• セキュリティ監視
• 障害調査
• システム運用の可視化
• 監査やアクセス傾向の分析

地味なログに見えますが、実務ではかなり重要な観測ポイントです。

DNSクエリログはどんな場面で使われるのか

セキュリティ監視で使う場合

DNSクエリログは、セキュリティの現場でよく使われます。

たとえば、社内端末が不審なドメインへ問い合わせていないか、異常に多くの名前解決をしていないか、存在しないドメインへの問い合わせが大量に出ていないかといった観点で確認されます。

マルウェアや不正プログラムは、外部のサーバーへ接続する前にDNS問い合わせを行うことがあります。

そのため、DNSクエリログは不審な挙動の兆候を見つけるヒントになりやすいのです。

ただし、ここで大切なのは、DNSログだけで即座に攻撃と断定はできないということです。

長いサブドメインやTXTレコードの多用などは、正常なSaaS連携や認証処理でも起こりえます。

DNSログは、あくまで「怪しい動きの入口を見つける材料」と考えるのが適切です。

障害調査で使う場合

Webサイトやシステムに接続できないとき、原因はアプリだけとは限りません。

実際には、DNS解決の失敗が原因になっているケースもあります。

たとえば、

• 存在しないドメイン名を引いている
• DNSサーバー側で解決に失敗している
• 一部の端末だけ異なる名前解決をしている
• キャッシュの影響で古い情報が残っている

といった問題が起こることがあります。

このようなとき、DNSクエリログを確認すれば、問い合わせ自体が発生しているか、どんな結果が返っているかを追いやすくなります。

接続障害の原因切り分けでは、とても有効な情報源です。

運用の可視化に使う場合

DNSクエリログは、運用面でも役立ちます。

どの端末やサーバーが、どのドメインに対して継続的に問い合わせているかを見ることで、利用中の外部サービスや依存先の把握につながるからです。

たとえば、

• 社内でよく使われているSaaS
• どの外部サービスに依存しているか
• 特定システムが定期的に通信している先
• 新しく増えた外部ドメイン

といったものを把握しやすくなります。

環境によっては、普段意識していなかった外部依存が見えてくることもあります。

監査や分析に使う場合

一定期間DNSクエリログを保存しておけば、過去の状況をあとから確認できます。

たとえば、インシデントが起きた後に「その時期にどの端末がどのドメインを引いていたか」をさかのぼって調査することができます。

また、問い合わせ件数やドメインの傾向を集計すれば、通常時のパターンと異常時の違いを見つけやすくなります。

ただし、DNSログは量が多くなりやすいため、保存期間や集計方法をあらかじめ設計しておくことが大切です。

DNSクエリログには何が記録されるのか

DNSクエリログに含まれる項目は、使っている製品やクラウドサービスによって異なります。

ただし、多くの場合は次のような情報が記録されます。

問い合わせ時刻

いつDNS問い合わせが行われたかを示す情報です。

ログ分析では最も基本になる項目です。

問い合わせ元

どの端末やサーバー、あるいはどのシステムから問い合わせが行われたかを示します。

クライアントIPやクラウド環境の識別情報が含まれることがあります。

問い合わせた名前

どのドメイン名やホスト名を問い合わせたのかが記録されます。

たとえば example.com や api.example.com のような名前です。

クエリタイプ

どの種類のレコードを問い合わせたのかを表します。

A、AAAA、MX、TXT、CNAMEなどがここに入ります。

応答コード

問い合わせの結果を示す情報です。

正常だったのか、存在しない名前だったのか、サーバー側で失敗したのかなどを把握できます。

追加情報

環境によっては、解決先やクラウドリソース情報、解決経路に関するメタデータが含まれることもあります。

よくあるDNSクエリタイプ

DNSではさまざまな種類の問い合わせが行われます。

代表的なものを知っておくと、ログが読みやすくなります。

Aレコード

IPv4アドレスを問い合わせるときに使われます。

AAAAレコード

IPv6アドレスを問い合わせるときに使われます。

CNAMEレコード

ある名前が別の名前の別名であることを示します。

MXレコード

メールを配送する先のメールサーバーを示します。

TXTレコード

テキスト情報を保持するためのレコードです。

SPF、DKIM、DMARC、ドメイン認証、所有確認などでもよく使われます。

NSレコード

そのドメインを管理するDNSサーバーの情報を示します。

PTRレコード

逆引きで使われるレコードです。

SRVレコード

特定のサービスの接続先情報を示します。

特にWeb運用やメール運用では、TXTレコードやMXレコードを意識する場面が多くなります。

よく出てくる応答コード

DNSクエリログを見るときは、結果を示す応答コードも重要です。

NOERROR

正常に処理できたことを示します。

NXDOMAIN

問い合わせた名前が存在しないことを示します。

SERVFAIL

DNSサーバー側で解決に失敗したことを示します。

REFUSED

問い合わせが拒否されたことを示します。

これらの応答コードの増減を見ることで、設定ミスや障害、不審な問い合わせ傾向の把握につながります。

DNSクエリログはどう読めばいいのか

DNSクエリログは、1件だけ見ても判断しにくいことが多いログです。

そのため、実際には傾向で読むことが大切です。

たとえば、次のような見方があります。

• 特定の端末だけ問い合わせ件数が極端に多い
• 深夜帯にだけ特定ドメインへの問い合わせが増える
• NXDOMAINが急増している
• 普段見ないドメインが急に増えた
• 特定のクエリタイプだけ異常に多い

こうした変化は、障害や不審な挙動の調査のきっかけになります。

ただし、DNSログに少し不自然な特徴があったとしても、それだけで異常と決めつけるのは危険です。

正常なCDN、メール認証、SaaS連携、検証処理でも似たような動きが出ることはあります。

DNSクエリログは、断定の証拠というより、深掘り調査の出発点として考えるのが実務的です。

DNSクエリログの限界とは

DNSクエリログは非常に便利ですが、何でもわかるわけではありません。

見える範囲には限界があります。

実際の通信成功まではわからない

DNS問い合わせがあったとしても、その後のTCP接続やHTTP通信まで成功したとは限りません。

名前解決に成功しても、通信先が落ちていたり、TLSやアプリ処理で失敗したりすることはあります。

URLのパスまでは見えない

DNSログで通常わかるのは、問い合わせたドメイン名までです。

example.com/login のようなURLの /login 部分は、DNSではなくHTTPの情報なので、DNSクエリログからは見えません。

キャッシュの影響を受ける

DNSはキャッシュを使う仕組みなので、同じ問い合わせが毎回必ずログに残るわけではありません。

一度解決された結果が再利用されれば、新しいDNS問い合わせ自体が発生しないことがあります。

ログの種類によって意味が違う

DNSサーバーのクエリログ、監査ログ、解析ログ、EDRが収集したイベント、ネットワーク機器の観測ログは、それぞれ性質が異なります。

同じ「DNS関連ログ」でも、何を元に見ているのかを区別しないと解釈を誤ることがあります。

DoHやDoTがあるとDNSログはどう変わるのか

最近は、DoH（DNS over HTTPS）やDoT（DNS over TLS）のように、DNS問い合わせを暗号化して送る方式も使われています。

このような仕組みが使われると、従来の平文DNSだけを前提にした観測では、可視性が下がることがあります。

特に、未管理のDoHやDoT、あるいはアプリ独自の名前解決が使われると、組織側の通常のDNSクエリログだけでは把握しにくくなることがあります。

ただし、DoHやDoTが使われているからといって、必ず完全に見えなくなるわけではありません。

企業管理下のDNS基盤やセキュリティ製品を経由している場合は、引き続き観測できるケースもあります。

DNSクエリログはどこで取得されるのか

DNSクエリログは、主に次のような場所で取得されます。

DNSサーバーやDNSリゾルバ

もっとも基本的な取得元です。

名前解決を処理する基盤そのものにログが残ります。

クラウドのDNSログ機能

クラウド環境では、DNSクエリログをマネージドに収集できる仕組みが用意されていることがあります。

監査ログや診断ログ

DNS製品によっては、通常のクエリログとは別に、監査用や診断用のログ機能が用意されています。

セキュリティ製品や監視製品

DNS通信を周辺から観測し、補助的なテレメトリとして記録している場合もあります。

ただし、これは純粋なDNSサーバーのクエリログとは別物であることも多いため、注意が必要です。

まとめ

DNSクエリログとは、DNSへの問い合わせと、その処理結果を記録したログです。

これを見ることで、いつ、どこから、どの名前に対して問い合わせが行われ、どう処理されたのかを把握できます。

主な用途は、セキュリティ監視、障害調査、運用可視化、監査や分析です。

一方で、DNSクエリログは万能ではなく、実際の通信成功まではわからないこと、URLパスまでは見えないこと、キャッシュやDoH/DoTの影響を受けることなど、理解しておくべき限界もあります。

DNSクエリログは、通信そのものの中身ではなく、通信の入口にある名前解決の履歴を見るためのものです。

だからこそ、問題の早期発見や原因切り分けにおいて、非常に価値の高いログだといえます。

よくある質問

DNSクエリログがあれば、アクセス先のURLまでわかりますか？

通常はわかりません。

わかるのは主にドメイン名までで、URLのパスはHTTP側の情報です。

DNSクエリログが残っていれば、実際に通信したと断定できますか？

断定はできません。

DNS問い合わせの後に通信が失敗している可能性もあります。

DNSクエリログだけで不正通信を見つけられますか？

ヒントにはなりますが、DNSログだけで断定するのは難しいです。

ほかのログと組み合わせて判断するのが基本です。

Web担当者にもDNSクエリログの知識は必要ですか？

はい。

ドメイン運用、メール認証、CDN、外部タグ、API接続など、Web実務とも関係が深いため、基本を理解しておくと役立ちます。

以上、DNSクエリログについてでした。

最後までお読みいただき、ありがとうございました。