DNSSEC/InsecureDelegationProofについて、ここに記述してください。

1. DNSSEC非対応の委譲（委任）に見せかけた返事を検出する

http://permalink.gmane.org/gmane.ietf.dnsext/20656 (検索でヒット）

2. dnsext ML

http://www.ietf.org/mail-archive/web/dnsext/current/msg11438.html 

That is, the attacker uses the existing NSEC for secure.foo.example.
Note however, that this NSEC record's type map does not have the DS bit set.
So, if you are a naive validator,
you might just follow the referral,
noting it is insecure (because the DS bit isn't set),
but fail to notice that it shouldn't have been a delegation at all.

Hence the advice.

DNSSEC/RFC4956

3. dnsext-dnssec-bis-updates-12

http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-12#section-4.4 

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.

DNSSEC/RFC4035/Section_5.2の記述では十分でないので、「追加の検査項目」が明示されている。

-- ToshinoriMaeno 2011-07-05 01:08:11

JPRSの日本語訳　（一部、読みやすさのために、整形した） 

4.4. 署名付き委任の検証

   [RFC4035]のセクション5.2において、委任が"Secure(検証成功：信頼度高)"
   ではないことをバリデータが証明する場合、NSEC(またはNSEC3)のタイプビット
   マップにDSおよびSOAビットが不在であるか検査する必要があると規定している。

[これだけでは不十分なので、以下がある。] 

   バリデータは、一致するNSEC(またはNSEC3) RRにNSビットが存在するか
　検査しなければならない(つまり委任が実際に存在することを証明する必要がある)。
   あるいは、当該委任がOpt-Outフラグの設定されたNSEC3 RRでカバーされている
   ことを確認する必要がある。この検査を行わない場合、偽造された未署名委任を
   使用して、既存の署名レコードが未署名であると明示できてしまうかもしれない。

つまり、DNSSEC非対応の委譲（委任）に見せかけた返事を検出するための検査が必要ということである。-- ToshinoriMaeno 2011-07-13 00:02:36