## page was renamed from DNSSEC/Non-Existence_Proofs
DNSSEC/Non-Existence_Proofsについて、ここに記述してください。

== dnsext-validator-api ==
http://tools.ietf.org/html/draft-hayatnagarkar-dnsext-validator-api-08.html

----


Internet-Draft       DNSSECbis Implementation Notes           March 2010

分かりにくい記述であるが、まとめると、こうなる。(委譲されている場合）

{{{
「親ゾーンのNSEC(3)は子ゾーンのRRの不在証明には使ってはならない」
}}}

-----

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)。
}}}