John Hinton wrote: > Do I just ask really hard questions or are my questions just not clear? > There has to be others on this list that are running nameservers via > CentOS. This seems to be a nasty issue that we who are running bind need > to get right. And the fix is really stupid for those running name servers behind firewalls. I can't say I'm an expert on this particular issue but from what I've read it seems like the attack depends on being able to send queries to the name server in question in order to predict the IDs that the system is generating. The way my DNS is setup at home is that I have 2 "external" name servers that do not allow recursion for domains that they are not responsible for other than for a couple trusted IPs(all of which are local). My main caching name server is internal to my network and cannot be directly queried from the internet. As such I think my exposure is pretty low. All of my name servers are setup to force their source port to be 53, I really really don't like the idea of opening up tens of thousands of ports back to my name servers. So I suspect, if your caching name servers are only vulnerable if they can be sent queries from the attacker. If your internal network is trusted then I think your fairly safe as long as you don't allow access to the caching name servers externally. And of course run dedicated name servers for authoritative hosting. I plan to have a similar setup at my company, the external authoritative servers are not behind a firewall(F5 Global traffic managers), the internal ones are not accessible outside the network. DNS cache poisoning is the least of my worries if an attacker has access to the internal network. nate