The djbdns security guarantee

I offer $1000 to the first person to publicly report a verifiable security hole in the latest version of djbdns.

Examples of security holes:

Buffer overflows allowing attackers to take over DNS caches, such as the NXT bug in BIND before 8.2.2-P4 (1999), or the TSIG bug in BIND before 8.2.3 (2001), or the SIG bug in BIND before 4.9.11/8.3.4 (2002).
Buffer overflows allowing attackers to take over DNS servers, such as the IQUERY bug in BIND before 8.1.2-T3B (1998).
Buffer overflows allowing attackers to take over DNS clients, such as the CNAME bug in BIND's libresolv before 4.9.9/8.2.6/8.3.3/9.2.2 (2002), or the getnetbyname bug in BIND's libresolv before 4.9.11 (2002).
Buffer overflows allowing attackers to take over DNS utilities.

Examples of problems that do not qualify:

Bugs outside of djbdns, such as OS bugs or browser bugs. (People could seize control of BIND 9.1 through an OpenSSL buffer overflow, but that was a bug in OpenSSL, not in BIND.)
The vulnerability of DNS to forgery. (BIND's port reuse makes blind forgery much less expensive, but this is a quantitative difference, not a qualitative difference. The DNS architecture needs cryptographic protection.)
Denial-of-service attacks. (BIND 9's fragility makes denial of service completely trivial; but an attacker can easily take down the Domain Name System without using any of BIND's bugs. The DNS architecture needs to be decentralized.)

My judgment is final as to what constitutes a security hole in djbdns. Any disputes will be reported here.