[TriLUG] DNS Questions / Help

[Aaron S. Joyner]

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