2010年３月には公開されていたようですが、議論されていた様子がない。どうして？　どれも当然の指摘だと思うが。 

A Security Evaluation of DNSSEC with NSEC3
 Jason Bau, John Mitchell, Stanford University

http://www.isoc.org/isoc/conferences/ndss/10/pdf/17.pdf

Table 1. Summary of Contributions

Vulnerability Found; Prevention Advice

1. 4.5.1 Temporal Inconsistency Discovered

Resource Record remains valid in local resolver cache 
after expiration of signatures or key rollover (revocation) higher in attestation chain

Resolver Software: Resolver software sets RR TTL to depend on all signatures in attestation chain to trust anchor;
Resolver software periodically re-acquires zone keys to re-validate cached attestation chains
RFC: Propagate changes to RFC

2. 5.1.1 Glue Record Redirection Violation

Glue records may be forged to direct next recursive query to attack DNS server

Domain Operator: Use all secure delegations
Resolver Software: If forgery is suspected, query supposed authoritative zone to obtain signed version of glue records. (Even if no action is taken, this vulnerability cannot result in acceptance of forged RR as final query answer)

3. 5.1.3 NSEC3 Opt-out Violation

NSEC3 opt-out may be used to prepend falsified owner name in domain,
resulting in vulnerability to cookie-theft and pharming

Domain Operator: Do not set NSEC3 opt-out flag
Website Designer: Do not use overly coarse cookie “domain” setting

4. 5.1.4 Mismanaged Signature Expiration

Replay of still valid A+RRSIG after IP-address move (Bernstein [11])

Domain Operator: Do not relinquish IP-address until all A+RRSIGs have expired

5. 5.4 NSEC3 Salt Post-Computation

NSEC3 salt is ineffectual

Domain Operator: Do not use salt. Increase number of hash iterations.

6. 5.1.2 Inter-operation with DNS

Inter-operation with standard-DNS child zones means insecure answer returned by DNSSEC resolver

Domain Operator: Adoption of DNSSEC; Do not interoperate DNSSEC with DNS

7. 3.1.2 Interoperability with DNS Limitations

Lack of user-interface indicator of secure vs. insecure DNSSEC query result exposes end-user to exploitable insecure DNSSEC query result

User Software: Provide DNS security indicators
RFC: Disallow insecure answers from DNSSEC resolvers once DNSSEC adoption ramps up

8. 5.3.1 Eliminating Vulnerabilities By Attested Cache Resolver Design

Network attacker can arbitrarily manipulate DNSSEC reply header and status bits

Resolver Software: Do not trust header bits. Resolver validates reply only using internal state and signed RRs.
ISP: Cannot trust remote server’s DNSSEC validation. Must request all DNSSEC RRs to validate at local resolver.

9. 5.3.1 Eliminating Vulnerabilities By Attested Cache Resolver Design

Network attacker can arbitrarily add / subtract / mangle RRs in DNSSEC reply

Resolver Software: Build attested cache for answering user queries using only authoritative signed RRs contained in DNSSEC replies

-- ToshinoriMaeno 2011-07-03 23:19:55