mark = Mark Suter john = John Coutts john> I complained long ago about this situation long ago and couldn't get anyone to john> listen. We have been hit twice, and both times the only common link was john> webpower.com. The problem originates when a ficticious domain is registered and john> points to a DNS that the hacker has access to. The hacker then somehow loads john> the DNS records in the cache of the targeted DNS claiming to have authority for john> the .com domain. When someone in your domain requests the ficticious site, it john> then supplies a non-authoratative response to your DNS and replaces the john> information in your cache for the .com domain. Any subsequent requests to your john> DNS for a non-cached .com domain goes to one of the webpower.com servers, which john> of course can't respond properly. mark> I thought that cache poisoning was corrected in Bind 8.1.1, as mark> the following CERT advisory indicates. mark> mark> http://www.cert.org/advisories/CA-97.22.bind.html mark> mark> If we were running 4.9.3, then I could understand; however, we mark> are running 8.2.2-P5. Are you aware of a new form of cache mark> poisoning? To answer myself, "Yes and No." Your forwarder can be your worst enemy ;) See below for how... john> The only cure is to set your DNS to accept authoratative answers only. mark> I've had a look at the options for bind, as follows, and I can't mark> see any "accept authoratative answers only" option - we've done mark> everything is last year's AusCERT Advisory, as follows. mark> mark> http://www.isc.org/products/BIND/docs/config/options.html mark> ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos mark> mark> What do you recommend we do? I have spoken with several people and have received the following suggestions, so I am replying to my own post. * Remove any forwarders. If you specify a forwarder, then named will trust the answers returned. Named assumes that the forwarder has done all the checks - to repeat the checks would amount to not using a forwarder ;) You are only a good as the weakest link. Going direct enables your nameserver to employ these "sanity checks", thus allowing your nameserver to reject bogus data. * Enable host-statistics. With this option enabled, as follows, the source of each item is shown in the dump produced by "ndc dumpdb". This does use more memory, so keep a watch on the core size - you do not want to be using swap. options { ... host-statistics yes; // Who told me that? }; For example, the following shows that my nameserver learned about pobox.com from 198.17.208.67 and 208.210.124.35. $ORIGIN com. ... pobox 153018 IN NS NS2.ICGROUP.COM. ;Cr=answer [198.17.208.67] 153018 IN NS NS1.ICGROUP.COM. ;Cr=answer [198.17.208.67] 153018 IN NS NS3.ICGROUP.COM. ;Cr=answer [198.17.208.67] 66618 IN A 208.210.125.1 ;Cr=auth [208.210.124.35] * Configure named to automatically treat known "bad" nameservers as bogus, as in the following example for our webpower.com friends out there ;) server 204.180.135.105 { bogus yes; }; // myifriendsns1.webpower.com I have following these suggestions on some of our nameservers in an attempt to "catch out" our forwarder. If that is indeed the problem here, I shall be making a phone call... Yours sincerely, -- Mark John Suter | I know that you believe you understand suter@humbug.org.au | what you think I said, but I am not sure GPG key id F2FEBB36 | you realise that what you heard is not Ph: +61 4 1126 2316 | what I meant. anonymous -- Attached file included as plaintext by Listar -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.2 (GNU/Linux) Comment: Public key available from Keyservers or http://www.uq.edu.au/~suter/ iD8DBQE5nT0a7EsZXfL+uzYRAqYuAJ9Ws1cHi715XP3F+92CTHTrQeEqMQCeOpnj CitrdQfeJDnhLAu01rMJU0I= =b2nz -----END PGP SIGNATURE-----