DNSをパケットで確認すると何が分かるのか

nslookupやdigは名前解決の結果を確認するのに便利ですが、 パケットキャプチャーではその途中にある通信そのものを確認できます。

まずQueryとResponseの流れを理解する

PCがwww.example.comのIPv4アドレスを知りたいとします。 端末は設定されているDNSサーバーへAレコードを問い合わせ、DNSサーバーが結果を返します。

パケット一覧では2つのDNSパケットが基本

QueryとResponseには同じTransaction IDが入り、Wiresharkでも対応する要求と応答を関連付けて表示できます。 まずは「問い合わせが1つ、その応答が1つ」という基本形を見つけられるようにしましょう。

今回の検証構成

最も再現しやすいように、PCでWiresharkを起動し、nslookupでDNS問い合わせを発生させます。 IPアドレスやDNSサーバーは、自分の環境に読み替えてください。

WiresharkでDNS通信を取得する手順

1. 利用中のDNSサーバーを確認する
   ipconfig /allなどで、PCに設定されているDNSサーバーを確認します。
2. Wiresharkで使用中のインターフェースを選ぶ
   EthernetまたはWi-Fiのうち、実際に通信しているインターフェースでキャプチャーを開始します。
3. 表示フィルターへ dns を入力する
   DNSとして解析されたパケットだけを表示します。
4. nslookup www.example.comを実行する
   ブラウザのキャッシュに左右されにくい形で、DNS問い合わせを明示的に発生させます。
5. キャプチャーを停止する
   QueryとResponseを探し、送信元・宛先・Transaction IDを確認します。

1．DNSサーバーを確認する

C:\> ipconfig /all

イーサネット アダプター Ethernet:

   IPv4 アドレス . . . . . . . . . . : 192.168.10.10
   サブネット マスク . . . . . . . . : 255.255.255.0
   デフォルト ゲートウェイ . . . . . : 192.168.10.1
   DNS サーバー. . . . . . . . . . . : 192.168.10.53

2．WiresharkでDNSだけを表示する

dns

3．nslookupで通信を発生させる

C:\> nslookup www.example.com
サーバー:  dns.example.internal
Address:  192.168.10.53

名前:    www.example.com
Addresses:  （環境により異なります）

実際の応答IPアドレスは名前や時点、DNSサーバー、CDNなどによって変わる可能性があります。 演習では特定のIPアドレスを暗記するのではなく、Queryに対してどのレコードが返ったかを確認してください。

4．パケット一覧でQueryとResponseを確認する

DNS Queryの読み方

Queryでは、Transaction ID、Flags、Queriesセクションを中心に確認します。 WiresharkでQueryパケットを選び、「Domain Name System」を展開します。

確認ポイント1：Transaction ID

Transaction IDはDNSの問い合わせと応答を対応付けるための識別値です。 Queryが0x4a3bなら、対応するResponseでも同じIDを確認します。

確認ポイント2：Responseフラグが0

Queryでは「これは応答ではなく問い合わせ」という状態です。 Wiresharkの表示フィルターでは、問い合わせだけを次のように絞り込めます。

dns.flags.response == 0

確認ポイント3：問い合わせ名とType

Nameは「何という名前を調べているか」、Typeは「その名前について何の情報が欲しいか」を示します。

DNS Responseの読み方

Responseでは、Queryと同じTransaction IDか、Responseフラグが1か、RCODEが正常か、 Answersに期待する情報が入っているかを確認します。

確認ポイント1：Transaction IDがQueryと一致する

同時に多数のDNS通信が流れていても、Transaction IDを見ることで、どのResponseがどのQueryに対応するか確認できます。

確認ポイント2：Responseフラグが1

dns.flags.response == 1

確認ポイント3：RCODE

Responseには問い合わせの処理結果を示すReply code（RCODE）が含まれます。 「応答が返ったか」だけでなく、どの結果で返ったかまで確認します。

DNSヘッダーで確認する重要フィールド

DNSメッセージは、ヘッダーとQuestion・Answer・Authority・Additionalなどのセクションから構成されます。 障害切り分けでは全項目を暗記するより、次のフィールドから読むと効率的です。

RDとRAは混同しない

社内DNSサーバーへ問い合わせたつもりなのにRAが期待と異なる、REFUSEDが返る、といった場合は、 DNSサーバーの再帰設定や問い合わせ元制限を確認するきっかけになります。

A・AAAA・CNAMEとTTLの読み方

Aレコード

Aレコードは名前に対応するIPv4アドレスを表します。 クライアントがAを問い合わせ、AnswersにIPv4アドレスが返れば、IPv4向けの名前解決結果を取得できています。

AAAAレコード

AAAAレコードはIPv6アドレスを表します。 AとAAAAが近いタイミングで問い合わせられることは珍しくありません。

CNAME

CNAMEは別名を正規名へ対応付けるレコードです。 Response内で「問い合わせた名前 → CNAME → 最終的なA/AAAA」のように複数のレコードが表示される場合があります。

TTL

TTL（Time To Live）は、そのDNSレコードをキャッシュとして保持できる時間の目安です。 DNSレコード変更後に「一部端末だけ古いIPアドレスを参照する」といった事象では、TTLやキャッシュの影響も確認します。

UDP 53とTCP 53の違い

DNSはUDPだけのプロトコルではありません。通常の名前解決ではUDP 53をよく見ますが、TCP 53もDNSの正式な通信方式です。

TCビットに注目する

DNS ResponseのTC（Truncated）が1の場合、応答が切り詰められたことを示します。 その後、クライアントがTCPで問い合わせをやり直す流れが見えることがあります。

障害調査で使えるWiresharkフィルター

DNS調査では、まずdnsから始め、状況に応じて条件を追加します。

DNS障害をパケットで切り分ける

DNS障害では、QueryとResponseの有無を順番に確認すると原因候補を整理できます。

現場での確認順序

1. PCに設定されたDNSサーバーを確認する
2. WiresharkでQueryが送信されるか確認する
3. Queryの宛先DNSサーバーが正しいか確認する
4. Responseが返るか確認する
5. Transaction IDが一致するか確認する
6. RCODEを確認する
7. Answer RRsと返却レコードを確認する
8. DNSが正常なら、名前解決後のTCP/UDP通信へ調査を進める

調査結果の報告例

【事象】
PC-Aから業務サーバー server01.example.internal を名前指定すると接続できない。

【確認結果】
・PC-AのDNSサーバー設定は192.168.10.53で設計値と一致。
・PC-Aから192.168.10.53宛てのDNS Queryを確認。
・Query Nameは server01.example.internal、TypeはA。
・同一Transaction IDのDNS Responseを確認。
・Response CodeはNXDOMAIN。
・IPアドレスを直接指定した通信は別途到達性あり。

【判断】
クライアント～DNSサーバー間の通信断ではなく、
DNSサーバーが対象名を存在しない名前として回答している状態。
対象ゾーン／Aレコード登録内容を確認する。

DNSが見えないとき：DoH・DoT・キャッシュ

ブラウザでWebサイトを開いたのにdnsフィルターで何も表示されない場合、 すぐに「DNS通信が発生していない」と判断してはいけません。

学習ではnslookupを使う

「ブラウザを開いたのにDNSが見えない」という混乱を避けるため、この記事の基本演習ではnslookupを使います。 DNSパケット解析の学習と、ブラウザ固有のキャッシュ・暗号化DNSの挙動を切り分けられるからです。

DNSパケット解析のよくある勘違い

自分の言葉で説明する課題