DNS SECURITY / CRYPTOGRAPHIC TRUST
会社のポータルを開いたつもりが、偽のログインサイトにつながってしまう。もしDNSの応答そのものが偽装されたら、ブラウザは何を信じればよいのでしょうか。
DNSは、www.example.com のようなドメイン名からIPアドレスなどを調べる仕組みです。私たちはURLでWebサイトを指定しますが、通信先を決める過程ではDNSの情報を利用します。
たとえば本来のIPアドレスが 192.0.2.10 なのに、途中で偽の応答 203.0.113.66 を受け取ると、別のサーバへ接続しようとする可能性があります。攻撃者がログイン画面を模倣していれば、フィッシング被害につながります。
| 役割 | 何をする？ | 典型的な責任 |
|---|---|---|
| スタブリゾルバ | OSなどでDNSの問い合わせを開始 | 通常は設定された再帰リゾルバに依頼 |
| 再帰リゾルバ（キャッシュDNS） | 必要な権威DNSをたどって問い合わせ、結果をキャッシュする | DNSSEC検証を実行する構成が一般的 |
| 権威DNSサーバ | 管理するゾーンの正式なDNSデータを提供 | 署名付きゾーンではRRset・RRSIG・DNSKEY等を公開 |
ゾーンを管理する権威DNSが「このドメインのAレコードはこれ」と答え、再帰リゾルバが利用者に結果を返します。キャッシュは高速化に役立ちますが、誤ったデータを記憶すると、その後の多数の問い合わせに影響することがあります。
DNSキャッシュポイズニングは、リゾルバが偽の応答を本物と誤認してキャッシュしてしまう攻撃です。従来のDNSには、DNSレコードの作成者を電子署名で検証する共通の仕組みがありませんでした。
攻撃への緩和策の一つが送信元ポートのランダム化です。攻撃者が正しい問い合わせを推測して偽応答を当てる難易度を上げます。ただし、応答内容が本当に権限のあるゾーンから生まれたかを暗号学的に証明するものではありません。
| 性質 | DNSSECで扱う？ | 考え方 |
|---|---|---|
| データの完全性 | はい | 署名対象のRRsetが改ざんされていないことを検証 |
| データの出所の認証 | はい | 信頼の連鎖につながる鍵で署名されたデータかを検証 |
| 通信の暗号化・秘匿 | いいえ | DNSSECの署名はDNSの問い合わせ内容を隠さない |
| 通信相手とのセッション暗号化 | いいえ | DoT・DoHなどは別の目的で用いる |
| Webサイトの本人性・安全性 | いいえ | WebサーバのTLS証明書やアプリケーション対策の領域 |
DNSSECが守るのはDNSデータの信頼性であり、ネットワーク経路をTLSのように暗号化することではありません。権威DNSは秘密鍵で署名を準備し、検証側は対応する公開鍵を利用します。
① ゾーン管理者は、A・AAAA・MXなど同じ名前・同じ型のレコード集合（RRset）に対して署名を作成します。② 権威DNSはRRsetに加えて署名レコード RRSIG と公開鍵レコード DNSKEY を提供できる状態にします。③ 検証リゾルバは署名が期限内で、対象RRsetと一致することを確認します。④ さらにそのDNSKEYが信頼できるかを親ゾーンなどへ遡って検証します。
| レコード | 主な役割 | 覚え方 |
|---|---|---|
| DNSKEY | ゾーン内で署名を検証する公開鍵を提供 | 鍵そのもの |
| RRSIG | RRsetへの電子署名、対象型、署名期間などを示す | 署名そのもの |
| DS | 親ゾーンに置かれ、子ゾーンのDNSKEYに対応するダイジェストを保持 | 親と子の信頼をつなぐ |
| NSEC / NSEC3 | 要求された名前や型が存在しないことを署名付きで証明 | 存在しないことの証拠 |
具体例として www.example.com. IN A 192.0.2.10 に対して署名されたRRSIGがあるとします。攻撃者がAレコードだけを別のIPへ変更しても、そのRRsetと署名は一致しなくなり、正しい鍵での検証に失敗します。
ただしDNSKEYを同じ応答から拾ってきて検証するだけでは十分ではありません。攻撃者が偽の公開鍵と偽の署名をセットで送り込めるからです。そこで次の「信頼の連鎖」が必要になります。
リゾルバはあらかじめ信頼できる鍵情報（トラストアンカー）を持ちます。一般的にはルートゾーンの信頼情報を出発点に、親ゾーンの署名済みDSが子ゾーンのDNSKEYと対応するかを確認し、さらに子の署名を確かめます。
たとえば「ルート → com → example.com」の順に鍵の正当性をたどり、その先で www.example.com のAレコードを検証します。これによって、単に「署名らしき文字列がある」だけではなく、信頼した起点までつながる署名だと確認できます。
| 検証状態 | 意味 | 利用時の見え方（一般例） |
|---|---|---|
| Secure | 署名と信頼の連鎖を検証できた | 正常回答 |
| Insecure | 検証可能な委任の結果、未署名ゾーンだと判断される | DNSSECで認証されないが回答可能 |
| Bogus | 署名が不正・期限切れ・信頼の連鎖不整合など | 検証リゾルバではSERVFAILなど |
| Indeterminate | 信頼の起点がなく、検証の可否を判定できない | 構成やポリシーに依存 |
重要なのは署名のないドメインがすべて攻撃扱いになるわけではないことです。安全に「この子ゾーンはDNSSEC未署名だ」と確認できた場合はInsecureと扱えます。これに対し、署名されるはずのゾーンで整合性が崩れるとBogusとなります。
攻撃者が本当は存在するレコードについて「そんな名前はありません」と偽る危険もあります。DNSSECではNSECやNSEC3というレコードを使って、名前・型の不存在を認証可能な形で示す仕組みがあります。
NSECは存在する名前の順序関係などを示し、NSEC3は名前のハッシュを利用します。両者にはプライバシーや運用上の特徴・限界があり、単純に「NSEC3なら全ての情報が隠せる」とは考えないでください。
DNSSECは重要ですが万能ではありません。攻撃者が正当なドメインを取得して署名付きの悪質サイトを運用した場合、DNSSEC検証が成功しても、そのサイトは安全とは限りません。また、DNSSECだけではDNS問い合わせの内容を第三者から隠せません。
| 目的 | 主な技術・対策 |
|---|---|
| DNSデータの真正性・完全性 | DNSSEC |
| DNS問い合わせ経路の暗号化 | DoT（DNS over TLS）、DoH（DNS over HTTPS） |
| Webサーバとの暗号化・認証 | HTTPS（TLS） |
| なりすましメールの対策 | SPF、DKIM、DMARC |
| 可用性の確保 | DNSの冗長化、監視、DDoS対策 |
| 技術 | 保護対象・仕組み | DNSをどう使うか |
|---|---|---|
| DNSSEC | DNSのRRsetを電子署名で検証 | DNSKEY・RRSIG・DSなどを利用 |
| 送信元ポートランダム化 | DNS偽応答を推測して当てる攻撃を難しくする | 問い合わせ時のUDP送信元ポートを変える |
| SPF | そのドメイン名のメール送信元として許可されたIPかを検査 | DNSのTXTレコード等に送信元ポリシーを掲載 |
| DKIM | 送信メールの選択されたヘッダと本文が署名に整合するかを検証 | DNSのTXT等で公開鍵を取得 |
| DMARC | SPF/DKIMの結果とFromドメインの整合を評価しポリシーを示す | DNS TXTにポリシーを公開 |
DKIMでも秘密鍵で署名して公開鍵で検証しますが、署名対象はメールです。一方DNSSECで署名されるのはDNSのRRset。同じ電子署名を使っていても、守っているデータが違います。
ゾーンに署名を付けるだけでは運用は終わりません。特に鍵のローテーションとDS更新の順序は障害につながりやすいポイントです。親ゾーンのDS情報と子ゾーンのDNSKEYが一時的に食い違うと、検証側が正当なDNSレコードを拒否する可能性があります。
| 確認項目 | 具体的な運用の観点 |
|---|---|
| 署名の期限 | RRSIGの期限切れを監視し、事前に再署名する |
| 鍵の保護 | 秘密鍵の権限管理・保管方法・バックアップを設計する |
| 鍵更新 | DNSKEY公開・DS登録の変更・キャッシュTTLを考慮して段階的に実施する |
| 監視 | 外部のDNSSEC検証リゾルバから複数拠点で名前解決を確認する |
| 移行・委任 | ドメイン移管・DNS事業者変更の際にDSと署名の整合性を確認する |
| 障害対応 | Bogus判定と未署名によるInsecureを区別して調査する |
DNSSEC対応リゾルバや権威DNSから付加情報を取得するときは、dig の +dnssec が便利です。以下はコマンドの例です。
# DNSSEC関連レコードを含めて問い合わせる
dig example.com A +dnssec
# DNSKEYを確認する
dig example.com DNSKEY +dnssec
# 親側に置かれたDS情報を確認する
dig example.com DS +dnssec
# リゾルバが検証済みとして返す場合のADフラグを確認
dig example.com A +dnssec実際の出力は対象ゾーンや利用リゾルバで異なります。+dnssec はDNSSECレコードの取得を要求する指定であり、それだけで手元の端末が検証を実施した証拠にはなりません。ADフラグも信頼できる検証リゾルバとの通信など前提を確認して解釈します。
署名、公開鍵、親のDS、期限を切り替えたときにどのような検証結果になるかを体験します。実際の暗号演算ではなく、DNSSECの判断条件を視覚化した教材です。
「次のステップ」で、どこでデータを取得して、どこで署名を検証するか確認してください。
ステップ 1 / 6：ブラウザ → 再帰リゾルバ
ブラウザは www.example.com のAレコードを調べたい。リゾルバに問い合わせる。
状況を選ぶか、検証条件を個別に切り替えてください。これは暗号演算を実行するものではなく、検証の考え方をモデル化したシミュレーターです。
DNSSEC検証の判定
RRsetの整合性・署名・公開鍵・親DS・有効期限を確認できました。信頼の連鎖がつながり、Secureとして扱えます。
「DNSのレコードが本当にゾーン管理者によるもので、書き換えられていないか検証したい」。どの仕組みが目的に合いますか？
DNSSECの重要な点は、①署名付きのDNSデータを公開する、②DNSKEYとRRSIGを照合する、③DSを通じて信頼の起点までたどる、という流れです。これにより、キャッシュポイズニングによる偽DNS応答を検出できるようになります。
送信元ポートランダム化は偽応答の推測を難しくする対策、SPFとDKIMはメールの認証技術です。同じDNSを使っていても目的は異なります。「何に電子署名しているのか」「誰が何を検証するのか」で区別すると整理できます。