DNSSECはDNS応答を暗号化する技術ではなく、署名されたDNSデータが信頼できるゾーンにつながり、改変されていないかを検証する仕組みだ。検証リゾルバーは信頼アンカーから親DSと子DNSKEYをたどり、回答RRsetの署名を確認する。署名されない委任はinsecureの場合があり、失敗だけで攻撃とは断定できない。

盾と錠前のある三層の色付き台、接続線、チェックマーク付きカードで構成された抽象的なセキュリティイラスト

概念図であり、実際のDNS通信ではない。

検証は信頼アンカーから始まる

検証リゾルバーは設定されたtrust anchorから検証を始め、検索ごとにルートサーバーへ接続するわけではない。公開DNSではルートゾーンのDNSKEY情報が起点となる。署名された委任を階層に沿って確認するが、ルートがすべてのドメインの内容を直接保証するわけではない。RFC 4033

たとえば www.example.com の名前解決を考える。検証リゾルバーは設定済みのルートtrust anchorから始め、認証された委任を .com、さらに example.com へとたどる。これは手順を説明する仮想例で、この名前が現在DNSSECに対応しているという確認ではない。実際に検証できるかは、各ゾーンが公開するレコードと署名に依存する。RFC 4033

DSが親と子のゾーンを結ぶ

子ゾーンはDNSKEYを公開し、リソースレコード集合に署名する。親ゾーンのDSには子DNSKEYにつながるdigestが記録される。検証側はその対応を確認してから、認証された鍵情報で回答RRsetのRRSIGを検証する。DNSSECはDNSデータに署名するもので、通信の暗号化とは異なる。RFC 4035 ICANN

DSは親ゾーン側にある子DNSKEYへのリンクである。検証側は親が公開するDSを確認し、子のDNSKEY情報と対応することを確かめてから、子ゾーンのデータ署名を検証する。親の委任情報と子の鍵が一致しなければ、期待される信頼経路を完了できない。鍵のロールオーバーでは親と子の公開手順を調整する必要があるが、特定の日程やアルゴリズムを一律に推奨するものではない。実際の手順は登録事業者とゾーン運用者の案内に従う。RFC 4035

検証状態を区別する

署名経路が有効ならsecure、正当に署名されていない委任ならinsecureとなり得る。署名不整合はbogus、情報不足はindeterminateとなる場合がある。名前解決の失敗だけでは攻撃の証拠にならず、設定や公開データの誤りも原因になり得る。RFC 4033

署名は個々の回答行を独立した証明書にするのではなく、同じ名前と型のリソースレコード集合、RRsetを対象にする。検証側はデータ集合と署名を合わせて確認する。要求データが存在しない場合を認証する仕組みもあるが、それは署名済みゾーン内のDNSデータについての限定的な証明であり、インターネット上の全名称の一覧ではない。肯定的な回答も不在の証明も、ゾーンの署名関係に基づいて確認する。RFC 4033

専門家の視点：DNSSECが保護しない範囲

ICANNは、DNSSECがDNSデータの出所認証と完全性を提供すると説明している。問い合わせの秘匿、Webサイトの本人確認、可用性までは保証しない。有効な署名もデータ内容の正しさを保証するものではなく、鍵との関係に照らして署名が検証できることを示す。ICANN

運用上は親ゾーンのDS公開と子ゾーンのDNSKEY・署名公開が対応している必要がある。更新が遅れたり情報が食い違ったりすると、攻撃がなくても検証に失敗し得る。調査では、失敗する名前と委任箇所を特定し、親のDSと子のDNSKEYの対応、リゾルバーが記録した検証状態を確認する。エラーは切り分けの材料で、それだけで攻撃を証明するものではない。RFC 4035 ICANN

Sources