Folks, > * 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. The bogus .com NS list has re-occurred. The following are from named_dump.db on Cuscus.cc.uq.edu.au and Krefti.cc.uq.edu.au, respectively. As you can see, we had host-statistics on ;) com 82814 IN NS myifriendsns1.webpower.com. ;Cr=auth [203.101.255.15] 85146 IN SOA webpower.com. postmaster.webpower.com. ( 169 10800 900 604800 86400 ) ;Cr=auth [204.180.135.105] com 74970 IN NS myifriendsns1.webpower.com. ;Cr=auth [203.101.255.15] 86175 IN SOA webpower.com. postmaster.webpower.com. ( 169 10800 900 604800 86400 ) ;Cr=auth [204.180.135.105] Both Cuscus and Krefti were forwarding to dns0.optus.net.au and ns-forward.uq.net.au. Both of these forwarders use Bind 8.2.2-P5 and the latter is under our control. The bogus NS list apparently came from ns-forward.uq.net.au and the bogus SOA is consistent with the bogus NS list. How is this be happenning? Does a misconfigured server like 204.180.135.105 mean any nameserver that is forwarding can pickup its bogus version of .com? Is it possible to have forwarders and not risk these bogus records? If so, how? 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/ iD8DBQE5qStu7EsZXfL+uzYRAkKiAJ9hbn8C6ODyiSw2RcrAsiM60wT3MACfb6Vl l66hRmRHvlecOWpUovDq944= =tGNx -----END PGP SIGNATURE-----