3. Services Provided by DNS Security (DNS セキュリティが提供するサービス)
ドメインネームシステム (Domain Name System, DNS) セキュリティ拡張は, DNS データに対する発信元認証 (origin authentication) および完全性保証 (integrity assurance) サービスを提供し, DNS データの非存在の認証されたメカニズムを含みます。これらのメカニズムを以下に説明します。
これらのメカニズムには DNS プロトコルへの変更が必要です。DNSSEC は4つの新しいリソースレコードタイプを追加します: リソースレコード署名 (Resource Record Signature, RRSIG), DNS 公開鍵 (DNS Public Key, DNSKEY), 委任署名者 (Delegation Signer, DS), および次の安全 (Next Secure, NSEC)。また, 2つの新しいメッセージヘッダビットを追加します: チェック無効 (Checking Disabled, CD) および認証済みデータ (Authenticated Data, AD)。DNSSEC RR の追加によって生じるより大きな DNS メッセージサイズをサポートするために, DNSSEC は EDNS0 サポート ([RFC2671]) も必要とします。最後に, DNSSEC は DNSSEC OK (DO) EDNS ヘッダビット ([RFC3225]) のサポートを必要とし, セキュリティ認識リゾルバがクエリで応答メッセージに DNSSEC RR を受信したいことを示すことができるようにします。
これらのサービスは [RFC3833] で説明されているドメインネームシステムへの脅威のほとんどから保護します。これらの拡張の制限についての議論は第 12 節を参照してください。
3.1. Data Origin Authentication and Data Integrity (データ発信元認証とデータ完全性)
DNSSEC は暗号的に生成されたデジタル署名を DNS RRset に関連付けることによって認証を提供します。これらのデジタル署名は新しいリソースレコード RRSIG レコードに保存されます。通常, ゾーンのデータに署名する単一の秘密鍵がありますが, 複数の鍵も可能です。例えば, 複数の異なるデジタル署名アルゴリズムのそれぞれに対する鍵がある場合があります。セキュリティ認識リゾルバがゾーンの公開鍵を確実に学習すれば, そのゾーンの署名されたデータを認証できます。重要な DNSSEC の概念は, ゾーンのデータに署名する鍵はゾーン自体に関連付けられており, ゾーンの権威ネームサーバには関連付けられていないということです。(DNS トランザクション認証メカニズムの公開鍵も [RFC2931] で説明されているようにゾーンに現れる可能性がありますが, DNSSEC 自体は DNS データのオブジェクトセキュリティに関係しており, DNS トランザクションのチャネルセキュリティには関係していません。トランザクションセキュリティに関連する鍵は異なる RR タイプに保存される場合があります。詳細は [RFC3755] を参照してください。)
セキュリティ認識リゾルバは, リゾルバに構成されたトラストアンカーを持つか, 通常の DNS 解決によってゾーンの公開鍵を学習できます。後者を可能にするために, 公開鍵は新しいタイプのリソースレコード DNSKEY RR に保存されます。ゾーンデータに署名するために使用される秘密鍵は安全に保持されなければならず, 実用的な場合はオフラインで保存されるべきであることに注意してください。DNS 解決を介して公開鍵を確実に発見するには, ターゲット鍵自体が構成された認証鍵または以前に認証された別の鍵によって署名されている必要があります。セキュリティ認識リゾルバは, 新しく学習した公開鍵から以前に知られている認証公開鍵への認証チェーンを形成することによってゾーン情報を認証し, その認証公開鍵は順にリゾルバに構成されているか, 以前に学習され検証されている必要があります。したがって, リゾルバは少なくとも1つのトラストアンカーで構成されている必要があります。
構成されたトラストアンカーがゾーン署名鍵である場合, 関連するゾーンを認証します, 構成された鍵が鍵署名鍵である場合, ゾーン署名鍵を認証します。構成されたトラストアンカーが鍵自体ではなく鍵のハッシュである場合, リゾルバは DNS クエリを介して鍵を取得する必要がある場合があります。セキュリティ認識リゾルバがこの認証チェーンを確立するのを助けるために, セキュリティ認識ネームサーバは, メッセージに利用可能なスペースがある場合, ゾーンの公開鍵を認証するために必要な署名を公開鍵自体とともに DNS 応答メッセージで送信しようとします。
委任署名者 (Delegation Signer, DS) RR タイプは, 組織の境界を越えて委任に署名することに関わるいくつかの管理タスクを簡素化します。DS RRset は親ゾーンの委任ポイントに存在し, 委任された子ゾーンの頂点で DNSKEY RRset を自己署名するために使用される秘密鍵に対応する公開鍵を示します。子ゾーンの管理者は次に, この DNSKEY RRset 内の1つ以上の公開鍵に対応する秘密鍵を使用して子ゾーンのデータに署名します。したがって, 典型的な認証チェーンは DNSKEY->[DS->DNSKEY]->RRset であり, "" は0個以上の DS->DNSKEY サブチェーンを示します。DNSSEC は, ゾーン内の他の DNSKEY RR に署名する DNSKEY RR の追加レイヤーなど, より複雑な認証チェーンを許可します。
セキュリティ認識リゾルバは通常, ルートの公開鍵に関する構成された知識に基づいて, DNS 階層のルートからリーフゾーンまでこの認証チェーンを構築します。しかし, ローカルポリシーは, セキュリティ認識リゾルバがルート公開鍵以外の1つ以上の構成された公開鍵 (または公開鍵のハッシュ) を使用することを許可する場合があり, ルート公開鍵の構成された知識を提供しない場合があり, またはこれらの公開鍵が検証可能な署名で適切に署名されている場合でも, 任意の理由で特定の公開鍵の使用をリゾルバに防止する場合があります。DNSSEC は, セキュリティ認識リゾルバが RRset の署名が DNSSEC の意味で "有効" であるかどうかを判断できるメカニズムを提供します。しかし, 最終的な分析では, DNS 鍵とデータの両方を認証することはローカルポリシーの問題であり, この文書セットで定義されたプロトコル拡張を拡張または上書きすることさえあります。さらなる議論については第 5 節を参照してください。
3.2. Authenticating Name and Type Non-Existence (名前と種別の非存在の認証)
第 3.1 節で説明されたセキュリティメカニズムは, ゾーン内の既存の RRset に署名する方法のみを提供します。同じレベルの認証と完全性で否定応答を提供する問題には, 別の新しいリソースレコードタイプ NSEC レコードの使用が必要です。NSEC レコードにより, セキュリティ認識リゾルバは, 他の DNS 応答を認証するために使用されるのと同じメカニズムで, 名前または種別の非存在に対する否定応答を認証できます。NSEC レコードの使用には, ゾーン内のドメイン名の正規表現と順序付けが必要です。NSEC レコードのチェーンは, ゾーン内のドメイン名間のギャップまたは "空白空間" を明示的に記述し, 既存の名前に存在する RRset のタイプをリストします。各 NSEC レコードは第 3.1 節で説明されたメカニズムを使用して署名および認証されます。