## page was renamed from DNSSEC/InsecureDelegationProof DNSSEC/InsecureDelegationProofについて、ここに記述してください。 == DNSSEC非対応の委譲（委任）に見せかけた返事を検出する == http://permalink.gmane.org/gmane.ietf.dnsext/20656 (検索でヒット） == 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]] == 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]]の記述では十分でないので、「追加の検査項目」が明示されている。 　NSビットが存在するかどうかの検査である。　署名なしの委譲が存在するかのように見せかけられる。 こういう類の抜けがないか、しっかり検証する必要がある。 -- ToshinoriMaeno <> ---- JPRSの日本語訳　（一部、読みやすさのために、整形した） {{{ 4.4. 署名付き委任の検証 [RFC4035]のセクション5.2において、委任が"Secure(検証成功：信頼度高)" ではないことをバリデータが証明する場合、NSEC(またはNSEC3)のタイプビット マップにDSおよびSOAビットが不在であるか検査する必要があると規定している。 }}} [これだけでは不十分なので、以下がある。] {{{ バリデータは、一致するNSEC(またはNSEC3) RRにNSビットが存在するか 　検査しなければならない(つまり委任が実際に存在することを証明する必要がある)。 あるいは、当該委任がOpt-Outフラグの設定されたNSEC3 RRでカバーされている ことを確認する必要がある。この検査を行わない場合、偽造された未署名委任を 使用して、既存の署名レコードが未署名であると明示できてしまうかもしれない。 }}} ---- つまり、DNSSEC非対応の委譲（委任）に見せかけた返事を検出するための検査が必要ということである。-- ToshinoriMaeno <>