I can add one more voice to the chorus, not that it will necessarily change anyone's mind. :) When I was at Yahoo! the question of whether to keep TCP open or not had already been settled, since they had found that if they didn't have it open there was some small percentage of users who could not reach them. Given the large total number of {users|dns requests}/day even a small percentage was too much to sacrifice. In addition to that, it was already well established policy that all RR sets should be kept under the 512 byte limit. I took this a step further and worked (together with others) on a patch to restrict the size of DNS answers to < 512 by returning a random selection of any RR set larger than that. Even with all of those precautions, I still measured a non-trivial amount of TCP traffic to our name servers, most of which was for valid requests. BTW, one of the things that a lot of people don't take into account in this little equation is the fact that the size of the QUERY will affect the size of the response. So, given this experience, my conclusions (for whatever they are worth) are: 1. You can restrict 53/TCP on an authoritative name server if you want to, but you will lose traffic because of it. 2. Whether this is an acceptable loss or not is a local policy decision, but you should understand the consequences before you act. 3. No matter what your policy is, you cannot guarantee that employees will never make a mistake and create an RR set larger than 512 bytes. 4. You cannot control the behavior of client software out in the world, no matter how much you rant about it. Others have already brought up the issues of DNSSEC, IPv6, etc. so I won't belabor how important having working TCP _and_ EDNS0 is going to be down the road. And last but not least, the yang of "My network, my rules" has a yin to balance it out, "Be liberal in what you accept ...." hth, Doug -- If you're never wrong, you're not trying hard enough