【実務・中級編】 DNSSEC検証状態の確認（digコマンドにおける+dnssecとAD/CDフラグ） – トラブルシューティング＆ネットワーク運用監視実践ガイド

DNSSECの「壁」を越えろ！ digコマンドで解き明かす、認証データの真実（AD/CDフラグ徹底解説）

おい、諸君！ NOCの戦場を駆け抜けてきた俺が、今日はちょっとばかり奥深い、でも実務では避けて通れない「DNSSEC」の話をしようじゃないか。Web API設計にインフラ運用、君たちが日々汗を流しているフィールドでは、もはや「セキュリティ」は当たり前の装備だ。その中でも、DNSレベルでの信頼性をガッチリ固めるDNSSECは、知っておかないと後で痛い目を見るぞ。

今回は、このDNSSECの「署名検証」がうまくいっているか、そしてその状態をどうやってdigコマンドで確認するのか、という点に焦点を当てる。特に、+dnssecオプションと、そこで現れるADフラグ、CDフラグの役割を、現場のリアルな視点から、分かりやすく、そして実践的に解説していく。RFCの文字面だけじゃ見えない「生きた」知識を、たっぷり仕込んでいくから、心してついてこいよ！

なぜDNSSECが必要なのか？パケットの旅路に「信頼」という名のガードマンを

まず、なぜDNSSECが必要なのか、そこから始めよう。君たちも知っての通り、DNSはインターネットの電話帳みたいなもんだ。ドメイン名という分かりやすい名前を、IPアドレスという機械が理解できる番号に変換してくれる。この変換プロセスがもし悪意ある第三者に乗っ取られたらどうなる？

DNSキャッシュポイズニング: 「あのサイト、実は詐欺サイトでした」なんてことが平気で起こる。フィッシングサイトに誘導されたり、マルウェアを仕込まれたり、想像するだけでゾッとするだろう？
なりすまし: 本来Aさんのサーバーに繋がるはずの通信が、なぜかBさんの悪意あるサーバーに繋がってしまう。大事な情報がダダ漏れだ。

DNSSECは、こうしたDNSの「なりすまし」や「改ざん」を防ぐための仕組みだ。公開鍵暗号技術を使って、DNS応答に「デジタル署名」を付与する。そして、問い合わせる側（リゾルバ）は、その署名を検証することで、応答が正当な権威DNSサーバーからのものであり、かつ途中で改ざんされていないことを確認できるんだ。

これは、まるで重要な書類に「公証人の印鑑」をもらうようなものだ。誰が、いつ、どのような内容で発行したかの証明になる。インターネットの基盤を、もっともっと信頼できるものにするための、まさに「ガードマン」なんだ。

digコマンドの「秘密兵器」： +dnssecオプションと、あのフラグたちの正体

さて、本題のdigコマンドだ。普段は名前解決のテストに使うことが多いだろうが、DNSSECの検証状態を確認する際にも、こいつは欠かせない。そこで登場するのが、+dnssecオプションだ。

1. +dnssecオプション：証拠を見せてくれ！

まずは、このオプションを付けてみる。

dig example.com A +dnssec

このコマンドを実行すると、普段の応答に加えて、DNSSEC関連の情報が追加で表示される。特に注目すべきは、応答のヘッダー部分だ。

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

この行のflagsの部分、普段はqr（Query Response）、rd（Recursion Desired）、ra（Recursion Available）あたりが見えることが多いだろう。しかし、+dnssecを付けると、さらに重要なフラグが現れることがある。

2. ADフラグ：「お墨付き」の証

DNSSEC検証の成否を語る上で、最も重要なのがADフラグ（Authenticated Data）だ。

ADフラグが立っている場合: これは、問い合わせたリゾルバが、DNSSECの署名検証を成功させたことを意味する。つまり、返ってきたデータは「本物」であり、信頼できる、とリゾルバが判断した証拠なんだ。君たちがAPIリクエストのレスポンスを「信頼できる」と判断するのと一緒だ。
ADフラグが立っていない場合: これは、リゾルバがDNSSEC検証を行わなかったか、あるいは失敗したかのどちらかだ。この場合、返ってきたデータが改ざんされていないという保証はない。

3. CDフラグ：「検証しないでくれ」というお願い

次にCDフラグ（Checking Disabled）だ。これはちょっとトリッキーだ。

CDフラグを付けて問い合わせた場合: dig example.com A +dnssec +cd のように+cdオプションを付けると、リゾルバに対して「DNSSECの検証をスキップしてくれ」とお願いしていることになる。
応答にCDフラグが付いている場合: これは、問い合わせ元が+cdオプションを付けてきた、つまり「検証しないでくれ」と要求してきたことを示している。

つまり、CDフラグは、DNSSEC検証の「有効/無効」を直接示すものではない。むしろ、「検証を無効にする」というリクエストが通ったかどうかを示すものなんだ。

実際の通信フローと、digコマンドの出力例

ここで、通信フローとdigコマンドの出力を具体的に見てみよう。

シーケンス図で見るDNSSEC検証の流れ

1. クライアント → リゾルバ: クライアント（君のPCやサーバー）が、リゾルバ（ISPが提供するものや、Google Public DNSなど）に名前解決を問い合わせる。この時、+dnssecや+cdオプションを付けていると、その情報もリゾルバに伝わる。
2. リゾルバ → 権威DNSサーバー: リゾルバは、問い合わせられたドメインの権威DNSサーバーに問い合わせる。この際、DNSSECの署名（RRSIGレコード）も一緒に要求する。
3. 権威DNSサーバー → リゾルバ: 権威DNSサーバーは、IPアドレス情報（Aレコードなど）と、それに対応する署名情報（RRSIGレコード）、そしてゾーンの信頼性を証明するためのキー情報（DNSKEYレコード）などをリゾルバに返す。
4. リゾルバ: リゾルバは、受け取った署名情報とキー情報を使って、DNSSECの検証を行う。

ADフラグを立てるかどうかの判断は、この検証結果に基づく。
CDフラグが立っている場合は、検証プロセス自体をスキップする。

5. リゾルバ → クライアント: 検証結果（あるいはスキップの有無）を反映させた応答をクライアントに返す。ここで、ADフラグやCDフラグが付与される。

digコマンドの出力例：正常系と異常系

ここでは、digコマンドの出力を例に、ADフラグとCDフラグの意味をより深く理解しよう。

例1： DNSSEC検証が成功した場合（ADフラグが立つ）

dig www.example.com A +dnssec

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1  <-- ここに 'ad' がある！

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

;; ANSWER SECTION:
www.example.com.        300     IN      A       93.184.216.34

;; AUTHORITY SECTION:
; (権威DNSサーバーからの追加情報。ここでは省略)

;; ADDITIONAL SECTION:
;; (DNSSEC検証に必要な追加情報。RRSIG, DNSKEYなど)

この例では、flagsの欄に ad が付いている。これは、リゾルバがDNSSECの署名検証に成功し、返ってきたAレコード（93.184.216.34）が正当なものであると認証したことを意味する。君たちがAPIから受け取ったデータが「真正」であると確信できる状態だ。

例2： DNSSEC検証が無効化されている場合（CDフラグが立つ）

dig www.example.com A +dnssec +cd

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54321
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1  <-- ここに 'cd' がある！

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

;; ANSWER SECTION:
www.example.com.        300     IN      A       93.184.216.34

;; AUTHORITY SECTION:
; (権威DNSサーバーからの追加情報。ここでは省略)

;; ADDITIONAL SECTION:
;; (DNSSEC検証に必要な追加情報。RRSIG, DNSKEYなど)

この場合、flagsの欄に cd が付いている。これは、我々が+cdオプションを付けて「検証しないでくれ」とリゾルバに指示したため、リゾルバがその指示に従った結果だ。この応答にはADフラグは付かない。

例3： DNSSEC検証が失敗した場合（ADフラグもCDフラグも立たない、またはSERVFAILになる）

もし、DNSSECの署名が壊れていたり、ゾーンのキー情報が間違っていたりすると、リゾルバは検証に失敗する。その場合、応答のstatusがSERVFAILになることが多い。

dig broken.example.com A +dnssec

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

このSERVFAILというステータスは、まさに「サーバー側で何らかのエラーが発生した」ことを示している。DNSSECの文脈では、検証エラーが原因であることが多い。ADフラグは当然立たない。

トラブルシューティングの現場：「なぜADフラグが立たないんだ！」

さて、ここからがNOCエンジニアの出番だ。君たちがAPIのレスポンスで「認証できません」というエラーに直面した時、原因を切り分けるための手順と似ている。

1. まずは基本から： digで名前解決できるか？

一番基本的なところだが、そもそも名前解決ができているか確認しよう。

dig example.com A

もし、これが失敗しているなら、DNSSEC以前の問題だ。ネットワーク接続、ファイアウォール、リゾルバの設定などを疑う必要がある。

2. +dnssecオプションで状態を確認

次に、+dnssecオプションを付けて、ADフラグが立っているか確認する。

dig example.com A +dnssec

ADフラグが立っている: おめでとう！DNSSEC検証は成功している。問題はDNSSECではない可能性が高い。APIのデータそのものや、アプリケーション側の処理を疑おう。
ADフラグが立っていない、かつstatus: NOERROR: ここからが本番だ。
使用しているリゾルバがDNSSECをサポートしているか？

ISP提供のリゾルバや、古いDNSサーバーを使っている場合、DNSSEC検証に対応していないことがある。Google Public DNS (8.8.8.8) や Cloudflare (1.1.1.1) など、DNSSEC対応を謳っているリゾルバに一時的に切り替えて試してみると良い。

クライアント側の設定は？

もしかしたら、クライアント側（君のPCやサーバー）でDNSSEC検証を無効にする設定になっているかもしれない。OSの設定や、ローカルのDNSキャッシュソフト（systemd-resolvedなど）の設定を確認しよう。

3. +cdオプションで検証そのものを無効化して試す

もし、+dnssecでADフラグが立たず、かつstatus: NOERRORのままであれば、一度+cdオプションを付けてみる。

dig example.com A +dnssec +cd

このコマンドで名前解決でき、かつCDフラグが立っている応答が返ってくるなら、それは「DNSSEC検証さえしなければ、名前解決はできる」ということだ。つまり、問題はやはりDNSSECの検証プロセスにあると特定できる。

4. SERVFAILが出る場合：権威サーバー側の問題か？

もし、+dnssecオプションを付けただけでSERVFAILになるなら、権威DNSサーバー側、またはゾーンのDNSSEC設定に問題がある可能性が高い。

DNSSEC署名の有効期限切れ: RRSIGレコードの有効期限が切れていると、検証は失敗する。
キー情報の不一致: DNSKEYレコードと署名のキーが一致しない、あるいはゾーンの信頼の連鎖（DSレコード）が正しく設定されていない場合も同様だ。

この場合は、ドメインの管理者に連絡し、DNSSECの設定を見直してもらう必要がある。

実践的なコード例： PythonでDNSSEC検証を試みる

digコマンドは便利だが、プログラムから自動的に検証状態をチェックしたい場面もあるだろう。Pythonのdnspythonライブラリを使えば、DNSSEC検証をプログラムから行うことができる。

まず、ライブラリをインストールする。

pip install dnspython

次に、PythonスクリプトでADフラグの有無を確認してみよう。

import dns.resolver
import dns.flags

# 検証したいドメインとレコードタイプ
domain = 'www.example.com'
record_type = 'A'

# Google Public DNS (8.8.8.8) をリゾルバとして使用
resolver = dns.resolver.Resolver()
resolver.nameservers = ['8.8.8.8']

try:
    # DNSSEC検証を有効にしてクエリを実行
    # dns.flags.AD は Authenticated Data フラグを有効にするためのフラグ
    # dns.flags.RD は Recursion Desired フラグ (通常はデフォルトで有効)
    answers = resolver.resolve(domain, record_type, flags=dns.flags.AD | dns.flags.RD)

    # レスポンスからフラグを取得
    # query() メソッドは Queryオブジェクトを返す
    # flags 属性は integer 値なので、dns.flags.to_text() で文字列に変換
    flags_text = dns.flags.to_text(answers.response.flags)

    print(f"ドメイン: {domain}, レコードタイプ: {record_type}")
    print(f"応答フラグ: {flags_text}")

    if 'AD' in flags_text:
        print("✅ DNSSEC検証に成功しました！ (ADフラグが立っています)")
    else:
        print("❌ DNSSEC検証に失敗したか、実行されませんでした。")

    # 名前解決されたIPアドレスなどを表示
    for rdata in answers:
        print(f"IPアドレス: {rdata.address}")

except dns.resolver.NXDOMAIN:
    print(f"エラー: ドメイン '{domain}' は存在しません。")
except dns.resolver.NoAnswer:
    print(f"エラー: ドメイン '{domain}' には {record_type} レコードがありません。")
except dns.resolver.SERVFAIL:
    print(f"エラー: DNSサーバーでSERVFAILが発生しました。DNSSEC検証に失敗した可能性があります。")
except Exception as e:
    print(f"予期せぬエラーが発生しました: {e}")

このコードでは、resolver.resolve()のflags引数にdns.flags.ADを指定することで、DNSSEC検証を有効にし、その結果としてADフラグが応答に含まれるかをチェックしている。SERVFAILが発生した場合の処理も追加しておいた。これは、APIエラーハンドリングで5xxエラーを捕捉するのに似ているだろう。

設定ファイルでの例： NginxでのDNSSEC検証設定

Webサーバーやリバースプロキシが、名前解決時にDNSSEC検証を行うように設定することも可能だ。例えば、NginxではresolverディレクティブでDNSサーバーを指定する際に、DNSSEC検証を有効にすることができる。

http {
    # DNSSEC検証を有効にするために 'valid=...' オプションと共に 'dnssec=on' を指定
    # ここでは Google Public DNS (8.8.8.8) を使用
    resolver 8.8.8.8 valid=30s dnssec=on;

    server {
        listen 80;
        server_name example.com;

        location / {
            # バックエンドサーバーへのリクエスト
            # ここで 'resolver' ディレクティブで指定されたDNSサーバーが使われる
            # API Gatewayなどでバックエンドのホスト名を解決する際にDNSSEC検証が行われる
            proxy_pass http://backend.example.com;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
}

このように、dnssec=onを指定することで、Nginxは名前解決の際にDNSSEC検証を行い、ADフラグが付いた信頼できる応答のみを受け入れるようになる。APIリクエストのルーティングや、バックエンドへの接続確立といった、インフラの根幹部分でセキュリティを強化できるわけだ。

まとめ：「見えない信頼」を、可視化する技術

DNSSECは、インターネットの「見えない信頼」を支える重要な技術だ。そして、digコマンドの+dnssecオプションと、ADフラグ、CDフラグは、その信頼が「今、どうなっているのか」を我々エンジニアに教えてくれる、まさに「可視化ツール」なんだ。

Web API設計やインフラ運用において、外部サービスへの接続や、ユーザーからのリクエストを捌く際に、その通信経路の信頼性は極めて重要だ。DNSSEC検証がうまくいっていないということは、その通信経路のどこかに「偽造された情報」が紛れ込むリスクがあるということ。それは、セキュリティインシデントの引き金になりかねない。

今回解説したdigコマンドの使い方、Pythonでの実践、そしてNginxの設定例。これらを頭の片隅に置いておくことで、君たちのインフラはより堅牢になり、運用監視の精度も格段に上がるはずだ。

もし、APIのレスポンスがおかしい、バックエンドに繋がらない、といったトラブルに遭遇したら、まずDNSSECの検証状態を疑ってみる。もしかしたら、その「原因不明」の裏には、DNSSECの「壁」が立ちはだかっているのかもしれない。

さあ、諸君！この知識を武器に、今日もインターネットの安全を守り抜いてくれ！

DNSSECの「壁」を越えろ！ digコマンドで解き明かす、認証データの真実（AD/CDフラグ徹底解説）

なぜDNSSECが必要なのか？ パケットの旅路に「信頼」という名のガードマンを

digコマンドの「秘密兵器」： +dnssecオプションと、あのフラグたちの正体

1. +dnssecオプション： 証拠を見せてくれ！

2. ADフラグ： 「お墨付き」の証

3. CDフラグ： 「検証しないでくれ」というお願い