Industry best practices (was Re: large organization nameservers sending icmp packets to dns servers)

Doug Barton dougb at
Thu Aug 9 23:13:12 UTC 2007

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) 

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 ...."




 	If you're never wrong, you're not trying hard enough

More information about the NANOG mailing list