Thanks you all for your help.
BTW, i run Bind 9.2.0 rc2, openssh v 3.0.1. I allow only udp 53 to coming in (no tcp 53 going in, in order to prevent zone transfer), but allow also outgoing tcp 53 connection, to allow to get @a.root-servers . I also maximum secured internal servers, not only restrictive rules on the firewall. But i let (i know i did a big fault) the ip_conntrack_ftp thas had a pb. I will upgrade as soon as possible. i beleive this has been the pb. I've stoped many services until i will sucessful this upgrade. Many thanks for your responses vincent >> > I advocate implementing DNS in a broken way, >> > and I have no good technical reason for it, >> > just some hearsay-it's-safer-that-way feeling. >> > >> > You are free to call that philosophy. I chose to call it stupidity. >> >> Call it what you like. When the next bind exploit comes out, my machine >> isn't going to get hacked. > >You hope... > >> Sure, it's not a technical reason. It's a security reason. > >That next bind exploit may just as well go through UDP. Your security >is thus only an _apparent_ gain. Whatever gain you think you have, comes >from your assumption that future bugs in bind, will more likely sit >on the TCP path. That may appear true by frequency analysis of past >bugs, but it's certainly not true in general. Now, if you don't >trust your software, or its developers, you'd be far better off not >running that software in the first place. Bandaiding around it won't >change the potential new holes introduced in the future. There are >alternatives, as you certainly know, from developers with a much >better track record of writing correct software. By plugging TCP DNS, >you give yourself an i-already-did-something excuse of not looking >for better DNS software. > >Anyway, 'nuff said for this iteration of that neverending topic. >Hope this mail is worth something for somebody reading the archives >in the future. > >Patrick >
