Lisa C. Boyd wrote: > I have a client who is asking me to explain some warnings on a DNS > Report. Can ya'll give me some easy to understand advice as to what > these warning are or how to fix them? > > --- Warning #1 --- > WARN TCP Allowed > WARNING: One or more of your DNS servers does not accept TCP > connections. Although rarely used, TCP connections are occasionally > used instead of UDP connections. When firewalls block the TCP DNS > connections, it can cause hard-to-diagnose problems. The problem > servers are: > > This site is hosted on a shared virtual web host (like most) so I'm > pretty sure we can ignore this warning because we have no control over > the name servers.
The other bits were covered pretty well, but I'll elaborate on this a bit more. As Jon said, your provider isn't allowing TCP connections to port 53 of their DNS server. That might seem like a big problem, except for the fact that 99% of DNS connections are UDP. Your query (almost) always starts out as UDP, which you send to the server. The server then figures out the response, and if it will fit in a single UDP packet, it sends it along. On the other hand, in the extremely rare circumstance that the entire response won't fit in a single UDP packet, the server sends a response to the client indicating that it should resend it's query via TCP. That client then makes a new TCP connection, resends the query, and gets the response. If things have to fall over to TCP, of course the connection takes much longer in-total, and consumes much more resources on both sides. So, thats "bad". Luckily, it's very unlikely you'll ever be in a position to craft such a large response packet, so don't worry about it. You may have picked up on the (almost) in that previous paragraph. The exception to the rule, when clients often start off doing TCP connections, is when they *know* the response is likely to be larger than a single UDP packet. That comes in to play when you do zone transfers, which request the entire zone, and the server provides the entire zone in a single response. These obviously (for all but the tiniest domains) don't fit in a single UDP packet, so they're delivered over TCP. So, now that we have the background, why would a provider not allow TCP DNS connections? Well the simple answer is that no one external slaves to them, and they want to avoid one more potential security problem. Historically, most exploits that have come around for any DNS system have involved TCP, because you need to send enough data to the server to cause a problem. If your server doesn't accept TCP connections, you're simply not going to be vulnerable to those types of requests. You can also avoid the overhead of establishing TCP connections that you're not likely to give a valid response to anyway (ala zone transfers). So, tell your client that you (or the provider) is being particularly paranoid about DNS connections, while not hampering the functionality in any way that will affect you. Spin it as a warm fuzzy feature. :) Enjoy! Aaron S. Joyner -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
