Further more, we found the following fact.
By this flaw, the attacker can inject poison very easily without relying on methods 1, 2, 3.
An attacker can take enough chance to overwrite cached NS RRSet of a zone by the following procedure.
RFC2181 5.4.1 "Ranking data" defines priority of caches as follows.
+ Data from a primary zone file, other than glue data,
+ Data from a zone transfer, other than glue,
+ The authoritative data included in the answer section of an
authoritative reply.
+ Data from the authority section of an authoritative answer,
+ Glue from a primary zone, or glue from a zone transfer,
+ Data from the answer section of a non-authoritative answer, and
non-authoritative data from the answer section of authoritative
answers,
+ Additional information from an authoritative answer,
Data from the authority section of a non-authoritative answer,
Additional information from non-authoritative answers.
In many cases, NS RRSet from the authority section of a non-authoritative answer is cached, if almost of all queries are for the child zones, and there are few chance to be requested for the zone itself.
From the specification described in Section 5.4.1 of RFC2181, data from the authority section of an authoritative answer has higher trustworthiness than the authority section of a non-authoritative answer.
As the result, such spoofed response from the faked child zone can replace NS RRSet cache from its parent's zone. Although it is considered that the response exceeds its authority, RFC2181 does not prohibit such behavior.
Someone may propose quick solution that all cache servers should refuse such responses. But, comparing NS RRSets among parent and children zones, we can find many inconsistent cases, especially in the case of changing name servers.
So this solution is hard to become practically applicable.