== DNSSECbis updates ==
July 10, 2011

http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-13
  4.1 [[DNSSEC/Non-Existence_Proofs]] <<BR>>
  4.2 [[DNSSEC/ResponsetoANYQuery]] <<BR>>
  4.3 [[DNSSEC/CheckforCNAME]] <<BR>>
  4.4 [[DNSSEC/InsecureDelegationProof]]

別のNSECをつけることによる妨害が可能という話らしい。
あるいは記述されていない検査を行う必要がある。

{{{
4.4. Insecure Delegation Proofs

   [RFC4035] Section 5.2 specifies that a validator, when proving a
   delegation is not secure, needs to check for the absence of the DS
   and SOA bits in the NSEC (or NSEC3) type bitmap.  The validator also
   needs to check for the presence of the NS bit in the matching NSEC
   (or NSEC3) RR (proving that there is, indeed, a delegation), or
   alternately make sure that the delegation is covered by an NSEC3 RR
   with the Opt-Out flag set.  If this is not checked, spoofed unsigned
   delegations might be used to claim that an existing signed record is
   not signed.
}}}

== 古い版の日本語訳 ==
http://jprs.jp/tech/material/id/draft-ietf-dnsext-dnssec-bis-updates-11-ja.txt

4.  セキュリティに関する懸念事項

   本セクションは、見落とした場合にセキュリティ上の問題を生じさせ得る
   事柄を明確化する。
{{{
4.1.  不在証明

   [RFC4035]のセクション5.4記載の不在証明検査アルゴリズムはあいまいである。
   具体的に、このアルゴリズムの記述では、先祖(訳注: 親、親の親等)ゾーン側の
   NSECまたはNSEC3 RRを使用して、子ゾーンのRRを不当に不在証明できてしまう
   可能性がある。

   "先祖側の委任(ancestor delegation)"のNSEC RR(またはNSEC3 RR)とは、
   以下の条件を満たすものである。

   ・ NSビットが設定されている
   ・ SOAビットが設定されていない
   ・ 対応するRRSIG RRの署名者名フィールドがNSEC RRの所有者名または
      NSEC3 RRのオリジナル所有者名よりも短い

   先祖側の委任のNSEC RRまたはNSEC3 RRに基づいて、ゾーンカット子側のいかなる
   RRの不在も想定してはならない(MUST NOT)。具体的に、委任元の(オリジナル)
   所有者名においては、DS RRを除く全RRが対象であり、当該所有者名よりも下位に
   おいては、タイプに関わらず全RRがその対象となる。

   同様に、先のアルゴリズムはDNAME RRと同じ所有者名を持つNSEC RRまたは
   DNAME RRと同じオリジナル所有者名を持つNSEC3 RRによって、DNAMEより下位に
   ある名前の不在証明ができてしまう。DNAMEビットが設定されたNSEC RRまたは
   NSEC3 RRに基づいて、NSEC/NSEC3 RRの(オリジナル)所有者名のサブドメインに
   おいて、いかなるRRの不在も想定してはならない(MUST NOT)。
}}}

4.2.  タイプANYの問合わせに対する応答の検証
{{{
   [RFC4035]には、QTYPE=*の場合にどのように応答を検証するかの記述がない。
   [RFC1034]のセクション6.2.2の記述は、"QTYPE=*に対する適正な応答には
   問合わせ名に対するRRsetのサブセットを含めてよい"となっている。
   つまり、QNAMEを所有者名とする全RRsetを応答する必要はない。

   QTYPE=*の応答を検証する場合、受信した応答に含まれる、QNAMEとQCLASSに
   一致する全RRsetを検証しなければならない(MUST)。どれか1つでも検証に失敗
   した場合、応答は"Bogus(検証失敗：信頼禁止)"と見なされる。QNAMEとQCLASSに
   一致するRRsetが存在しない場合、[RFC4035]のセクション5.4の(本文書で
   明確化した)規則に従い、一致するRRsetが存在しなかったという事実が検証
   されなければならない(MUST)。ここで明記しておくが、バリデータはQTYPE=*の
   応答に対して、QNAMEを所有者名とする全レコードの受信を期待してはならない。
}}}
4.3.  CNAMEの検査
{{{
   [RFC4035]のセクション5には、CNAMEに基づく(または基づくはずの)応答の検証に
   関してわずかな記述しかない。NOERROR/NODATA応答を検証する場合、バリデータは
   QNAMEおよびQTYPEに一致するNSEC RRまたはNSEC3 RRについて、問合わせタイプの
   ビットに加えてCNAMEビットも検査しなければならない(MUST)。この検査をしない
   場合、攻撃者は正常なCNAME(の存在を示す)応答をNOERROR/NODATA応答に変換
   できてしまう可能性がある。
}}}
4.4.  署名付き委任の検証
{{{
   [RFC4035]のセクション5.2において、委任が"Secure(検証成功：信頼度高)"
   ではないことをバリデータが証明する場合、NSEC(またはNSEC3)のタイプビット
   マップにDSおよびSOAビットが不在であるか検査する必要があると規定している。
   バリデータは、一致するNSEC(またはNSEC3) RRにNSビットが存在するか検査
   しなければならない(つまり委任が実際に存在することを証明する必要がある)。
   あるいは、当該委任がOpt-Outフラグの設定されたNSEC3 RRでカバーされている
   ことを確認する必要がある。この検査を行わない場合、偽造された未署名委任を
   使用して、既存の署名レコードが未署名であると明示できてしまうかもしれない。
}}}