On Sun, 30 Dec 2001 16:17, Jor-el wrote: > On Sun, 30 Dec 2001, Russell Coker wrote: > > Also don't allow recursion from outside machines. > > Why does this help?
When someone sends a recursive query to your server then they know (with a good degree of accuracy) what requests are going to be made by that server and what responses will be expected. So you can send a recursive query for www.microsoft.com, then send a dozen packets appearing to be responses from the Microsoft DNS servers giving an IP address of one of your servers. While you're at it you make sure that the false packets you sent had long TTL entries so that they stay in the cache for a while. Then suddenly you have all clients of that DNS server thinking that the MS servers are on your IP addresses (with lots of potential for abuse). Another issue is that if at some future time a bug is discovered in bind that results in a security hole when doing recursion then you want to only be vulnerable to your own network (who you can hunt down if they abuse it) rather than the rest of the world. > > Another possibility is to have the port for outgoing connections be > > something other than 53 (54 seems unused) and use iptables or ipchains to > > block data from the outside world coming to port 53. > > Security through obscurity? Quite frankly, I find this strategy Please read my messages carefully before flaming me. DNS cache machine sents out requests from source port 54 (not obscure - every administrator of every DNS server on the net can easily discover this). Recursive requests go to port 53 (getting a DNS client to even talk to another port is difficult or impossible depending on the client). iptables/ipchains blocks access to port 53 from untrusted IPs (IE everything outside your LAN or dialup pool). Bind will not be expecting any data other than replies to it's requests on port 54 (the port that is open to the outside world) so even if you screw up in your configuration of bind to not allow recursion from the outside world you're still protected. Smart people NEVER rely on only one layer of protection if they can avoid it. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]