Bind 8.2.3 cache corruption problem

[Chris Teakle]

On 21-April-2001 I posted a message to this list with the subject "Bind
8.2.3 picking up bogus .com data".

Basically our nameservers had been sporadically caching false NXDOMAINs
for names in .com which had been picked up from the hi2000.net
nameservers. We had to use the following to protect ourselves:

server 202.101.43.172 { bogus yes; };
server 211.90.223.103 { bogus yes; };

The only feedback I got was a couple of "me toos" and the following
from Kevin Darcy <kcd at daimlerchrysler.com>:

>After many messages back and forth, I finally got the webpower.com
>folks to stop claiming authority for .com and polluting the Internet
>with bogus referral information. The same thing needs to be done with
>the hi2000.net folks. Threaten to report them to their registrar
>(Network Solutions), if necessary.
>
>Until they fix this, everyone should declare these servers "bogus".

Today we discovered another case of cache corruption. This time it was
a bogus NXDOMAIN for 4.0.192.in-addr.arpa from ipdns2.hinet.net.  The
nameservers ipdns1.hinet.net & ipdns2.hinet.net are self-declared
authorities for in-addr.arpa and so presumably (by a mechanism I don't
fully understand) can potentially infect anyone's cache with bogus
in-addr.arpa data.

We have protected ourselves for now with:

server 168.95.1.14 { bogus yes; };
server 168.95.192.14 { bogus yes; };

Is there really nothing else one can do to protect against what
amounts to a denial of service attack? (Apart from complain to
their registrar)

What other known offenders are there which we should also mark as
bogus?

--
Chris Teakle                            | c.teakle at its.uq.edu.au
Infrastructure Management,              | tel +61 7 336 53690
Information Technology Services         | http://its.uq.edu.au/
The University of Queensland, Australia