皆さん、こんにちは！NOC（ネットワークオペレーションセンター）で日々、パケットの荒波と格闘しているシニアエンジニアです。
大規模データセンターの運用現場では、夜中に突然「Webサイトに繋がらない！」「名前解決がおかしい！」というアラートが飛び込んでくることが珍しありません。そんな時、私たちの相棒となるのがお馴染みの dig コマンドです。
DNSのトラブルシューティングといえば、単にドメイン名からIPアドレスを引くだけだと思っていませんか？ 実は、近年のインターネットの安全性を支える DNSSEC（DNS Security Extensions） の世界では、もう少し踏み込んだ「署名の検証」というドラマが裏側で繰り広げられています。
今回は、インフラの世界に一歩踏み出したばかりの皆さんに向けて、DNSSECの検証状態を確認するための dig コマンドの使い方を、身近な例えを交えながら優しく紐解いていきたいと思います。難しい用語が出てきても「一歩ずつ理解していきましょう！」の精神で進めましょう！
—
1. そもそもDNSSECってなに？ 〜手紙の「封泥」と「消印」の物語〜
私たちが普段使っているDNS（Domain Name System）は、いわばインターネットの「電話帳」です。example.com とブラウザに入力すると、「そのサーバーのIPアドレスは〇〇ですよ」と教えてくれます。
しかし、このDNSには大きな弱点がありました。悪意ある攻撃者が途中で通信を偽装し、ニセのIPアドレスを教えてユーザーを詐欺サイトへ誘導する「偽装工作（DNSキャッシュポイズニングなど）」ができてしまうのです。
これを防ぐために作られたのが DNSSEC です。
イメージしてください。
あなたが遠くにいる信頼できる友人から、非常に重要な手紙を受け取ったとします。本物の友人からの手紙であることを証明するために、どうすればよいでしょうか？
1. デジタル署名（消印と蝋印）: 友人は手紙に特殊な「蝋印（電子署名）」を押して送ります。
2. 検証（確かめ）: あなたの手元に届いたとき、その蝋印が本物か、途中で封が開けられていないかを専用の道具で確認します。
DNSSECは、まさにこの「蝋印」をDNSの応答データに付与し、途中で誰も内容を書き換えていないことを証明する仕組みなんです。
—
2. dig コマンドで「本物かどうか」を覗き見する
さて、本題に入りましょう。DNSサーバーがちゃんと「このデータは本物だよ（偽装されていないよ）」と証明してくれているか、あるいは私たちのコンピュータがそれを正しく検証できているかを調べるには、dig コマンドの +dnssec という特別なオプションを使います。
まずは、通常の dig と何が違うのか、実際にコマンドを叩いて（イメージして）確かめてみましょう。
基本の dig +dnssec コマンド
DNSSECが有効なドメイン（例として cloudflare.com などが有名です）に対して、以下のようにコマンドを実行します。
# +dnssec オプションをつけて、DNSサーバーに「署名データも一緒にちょうだい！」とリクエストする
dig +dnssec cloudflare.com Aこのコマンドを実行すると、通常のIPアドレス（A レコード）に加えて、RRSIG という見慣れないレコードが表示されます。これが先ほどお話しした「蝋印（電子署名）」のデータです。
「おっ、ちゃんと署名が付いて返ってきたぞ！」と確認できるわけですね。
—
3. 注目すべき2つの魔法の旗：「ADフラグ」と「CDフラグ」
dig コマンドの実行結果をよく見ると、画面のどこかに flags: という項目があります。ここには qr rd ra のようなアルファベットが並んでいますが、DNSSECのトラブルシューティングにおいて特に重要なのが、AD と CD という2つのフラグです。
それぞれ、身近な例えで意味を理解していきましょう。
① ADフラグ（Authentic Data：真正なデータです！）
- 意味: 「このデータは途中で誰も改ざんしていない、正真正銘の本物であることを検証しました！」という、DNSフルresolver（キャッシュサーバー）からの太鼓判です。
- 郵便の例: 郵便局の検品係が、「この小包、封印の蝋印が完全に一致しています。中身は安全です！」と太鼓判を押してあなたに手渡してくれた状態です。
dig の結果に ad という文字が含まれていれば、その名前解決は無事にDNSSECの検証をパスした安全なものだと言えます。
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
# ^^
# この「ad」フラグが立っていれば、検証成功の証です！② CDフラグ（Checking Disabled：ちょっと検証はストップして！）
- 意味: クライアント側（または途中の機器）が、「おい、DNSサーバーの方で勝手に署名の検証をしないでくれ！ 検証はこっち（手元）でするから、そのままのデータを送ってくれ！」と指示するフラグです。
- 郵便の例: 「中身の蝋印が本物かどうかは、私が自分で持っている鑑定ルーペで調べたいから、郵便局の人は勝手に剥がしたり判定しないで、そのままの状態で私に届けて！」とお願いする状態です。
現場でDNSSECの署名エラー（検証失敗）をデバッグする際、あえて +cd オプションをつけてDNSサーバーの検証をバイパスし、生の署名データを取り出して調査することがよくあります。
# あえて検証を無効化（Checking Disabled）して、生データを取得するコマンド
dig +cd cloudflare.com A—
4. トラブルシューティングの実践：なぜ「検証失敗」が起きるのか？
NOCの現場で最も頭を悩ませるのが、DNSSECの検証に失敗して SERVFAIL（サーバーエラー）という冷たい返事が返ってくるトラブルです。
「昨日まで見えていたWebサイトが、DNSSECを有効にした途端に見えなくなった…」
そんな時、エンジニアはどのように原因を切り分けるのでしょうか？
トラブルシューティングのステップ
1. まずは普通に引いてみる
dig example.com A これで SERVFAIL が返ってきた場合、DNSサーバー側で何らかの異常が発生しています。
2. 検証をあえて止めてみる（+cd の出番！）
dig +cd example.com A もし +cd をつけて（検証をスキップして）正常なIPアドレスが返ってきた場合、「データのデータ自体はあるけれど、署名の検証（お墨付きの確認）のプロセスでどこかが引っかかっている」という決定的な証拠になります。
3. 原因の多くは「時計のズレ」や「鍵の更新ミス」
DNSSECの署名には有効期限（タイムスタンプ）が厳密に設定されています。問い合わせを行っているサーバー（自分、またはキャッシュDNS）のシステム時計が数分でもズレていると、「署名が期限切れです！」と誤認され、容赦なくブロックされてしまいます。
また、ドメイントップの「親ゾーン」と「子ゾーン」の間で登録されている公開鍵（DSレコード）が不一致を起こしている場合も、検証エラーの原因となります。
—
5. まとめ
いかがでしたでしょうか？
一見すると難解な暗号技術やコマンドのオプションも、「手紙の封泥」や「郵便局の検品」という現実世界の仕組みに置き換えてみると、パケットがどんな意図を持ってネットワークを駆け巡っているのかが見えてきたのではないでしょうか。
+dnssec: 「署名（蝋印）も一緒に見せて！」とリクエストする。ADフラグ: 「安全性が確認されたよ（検証成功）」というお墨付き。CDフラグ: 「検証はこっちでするから、そのまま生データをちょうだい」と指示する。
現場でDNSのトラブルに直面したときは、慌てずにこれらのフラグやオプションを思い出してください。パケットの挙動を正しく読み解くことができれば、どんな障害も必ず解決の糸口が見えてきます。
それでは、次回のNOCブログもお楽しみに！ 安全で快適なネットワークライフを！
コメント