8. 一般的なDNSSEC

ほとんどのDNSSEC用語は[RFC4033]、[RFC4034]、[RFC4035]、および[RFC5155]で定義されています。DNSコミュニティで混乱を引き起こした用語をここで強調します。

DNSSEC認識とDNSSEC非認識(DNSSEC-aware and DNSSEC-unaware): これら2つの用語は、いくつかのRFCで使用されていますが、正式には定義されていません。ただし、[RFC4033]のセクション2は、「非検証セキュリティ認識スタブリゾルバ」、「非検証スタブリゾルバ」、「セキュリティ認識ネームサーバー」、「セキュリティ認識再帰ネームサーバー」、「セキュリティ認識リゾルバ」、「セキュリティ認識スタブリゾルバ」、および「セキュリティ無関心'何でも'」を含む多くのタイプのリゾルバとバリデーターを定義しています。(DNSSEC関連文書のいくつかの場所で使用される「検証リゾルバ」という用語も定義されていないことに注意してください。)

署名ゾーン(Signed zone): 「RRsetが署名され、適切に構築されたDNSKEY、リソースレコード署名(RRSIG)、Next Secure(NSEC)、および(オプションで)DSレコードを含むゾーン。」([RFC4033]のセクション2から引用。)他のコンテキストでは、ゾーン自体が実際に署名されているわけではなく、ゾーン内のすべての関連RRsetが署名されていることが指摘されています。それにもかかわらず、署名されるべきゾーンに署名されていない(またはオプトアウトされた)RRsetが含まれている場合、それらのRRsetは偽造されたものとして扱われるため、ゾーン全体を何らかの方法で処理する必要があります。

[RFC6840]の公開以降、署名ゾーンにはNSECレコードが不要になったことにも注意する必要があります:署名ゾーンには代わりにNSEC3レコードが含まれる可能性があります。[RFC7129]は、DNSSECが認証された存在の否定応答を提供するために使用するNSECおよびNSEC3メカニズムの追加の背景解説とコンテキストを提供します。

未署名ゾーン(Unsigned zone): [RFC4033]のセクション2は、これを「署名されていないゾーン」として定義しています。[RFC4035]のセクション2は、これを「このセクションのルールに従って、これらのレコード[適切に構築されたDNSKEY、リソースレコード署名(RRSIG)、Next Secure(NSEC)、および(オプションで)DSレコード]を含まないゾーン」として定義しています。[RFC4035]のセクション5.2の終わりには、ゾーンが未署名と見なされる追加の状況を定義する重要な注記があります:「リゾルバが認証されたDS RRsetにリストされているアルゴリズムのいずれもサポートしていない場合、リゾルバは子ゾーンへの認証パスを検証できません。この場合、リゾルバは子ゾーンを未署名として扱うべきです(SHOULD)。」

NSEC: 「NSECレコードは、セキュリティ認識リゾルバが、他のDNS応答を認証するために使用されるのと同じメカニズムで、名前またはタイプの非存在に対する否定応答を認証することを可能にします。」([RFC4033]のセクション3.2から引用。)簡単に言えば、NSECレコードは認証された存在の否定を提供します。

「NSECリソースレコードは2つの別々のものをリストします:権威データまたは委任ポイントNS RRsetを含む次の所有者名(ゾーンの正規順序で)、およびNSEC RRの所有者名に存在するRRタイプのセット。」(RFC 4034のセクション4から引用)

NSEC3: NSECレコードと同様に、NSEC3レコードも認証された存在の否定を提供します。ただし、NSEC3レコードはゾーン列挙に対して緩和し、オプトアウトをサポートします。NSEC3リソースレコードは[RFC5155]で定義されています。

[RFC6840]は、[RFC5155]が「[RFC4033]のセクション10で説明されているDNSセキュリティ文書ファミリーの一部と見なされるようになった」と述べていることに注意してください。これは、NSECレコードのみについて話している初期のRFCからのいくつかの定義は、おそらくNSECとNSEC3の両方について話していると見なされるべきであることを意味します。

オプトアウト(Opt-out): 「オプトアウトフラグは、このNSEC3 RRが未署名の委任をカバーする可能性があるかどうかを示します。」([RFC5155]のセクション3.1.2.1から引用。)オプトアウトは、不安全なゾーンへの委任を保護する高いコストに取り組みます。オプトアウトを使用する場合、不安全な委任である名前(および不安全な委任からのみ派生した空の非終端)は、NSEC3レコードまたはその対応するRRSIGレコードを必要としません。オプトアウトNSEC3レコードは、不安全な委任の存在を証明または否定することができません。([RFC7129]のセクション5.1から適応)

ゾーン列挙(Zone enumeration): 「連続したクエリを通じてゾーンの完全な内容を発見する慣行。」([RFC5155]のセクション1.3から引用。)これは「ゾーンウォーキング」とも呼ばれることがあります。ゾーン列挙は、推測者が可能なラベルの大きな辞書を使用してそれらの連続したクエリを送信するか、NSEC3レコードの内容をそのような辞書と照合するゾーンコンテンツ推測とは異なります。

鍵署名鍵(Key signing key, KSK): 「ゾーン内のエイペックスDNSKEY RRsetのみを署名する」DNSSEC鍵。([RFC6781]のセクション3.1から引用)

ゾーン署名鍵(Zone signing key, ZSK): 「エイペックスDNSKEY RRset以外の、署名が必要なゾーン内のすべてのRRsetを署名するために使用できるDNSSEC鍵。」([RFC6781]のセクション3.1から引用)KSKとZSKの役割は相互に排他的ではないことに注意してください:単一の鍵が同時にKSKとZSKの両方になることができます。また、ZSKはエイペックスDNSKEY RRsetを署名するために使用されることがあることにも注意してください。

組み合わせ署名鍵(Combined signing key, CSK): 「KSKとZSKの区別が行われない場合、つまり、鍵がKSKとZSKの両方の役割を持つ場合、シングルタイプ署名スキームについて話します。」([RFC6781]のセクション3.1から引用)これは「組み合わせ署名鍵」またはCSKと呼ばれることがあります。特定の鍵がZSK、KSK、またはCSKであるかを決定するのは、プロトコルではなく運用実践です。

セキュアエントリーポイント(Secure Entry Point, SEP): DNSKEY RDATAのフラグで、「信頼チェーンを構築する際にゾーンへのセキュアエントリーポイントとして使用されることを意図している鍵を区別するために使用できます。つまり、それらは親DS RRによって指し示される(または信頼アンカーとして構成される)ことになります。したがって、KSKとして使用される鍵にはSEPフラグを設定し、ZSKとして使用される鍵には設定しないことが推奨されますが、KSKとZSKの区別が行われない場合(つまり、シングルタイプ署名スキームの場合)、すべての鍵にSEPフラグを設定することが推奨されます。」([RFC6781]のセクション3.2.3から引用。)SEPフラグは単なるヒントであり、その存在または不在を使用して、検証中に特定のDNSKEY RRをKSKまたはZSKとして使用する資格を失格させることはできないことに注意してください。

DNSSECポリシー(DNSSEC Policy, DP): 「DNSSEC署名ゾーンのために実装されるセキュリティ要件と標準を定める」声明。([RFC6841]のセクション2から引用)

DNSSEC実践声明(DNSSEC Practice Statement, DPS): 「DNSSECポリシー(存在する場合)をサポートし、補足する実践開示文書であり、特定のゾーンの管理が高レベルで手順と制御を実装する方法を述べています。」([RFC6841]のセクション2から引用)