Restricting TCP / 53 on the firewall level

[Barry Margolin]

In article <a7nsab$k2l at pub3.rc.vix.com>, Jim Reid  <jim at rfc1035.com> wrote:
>>>>>> "Kristin" == Kristin Gorman <kgorman at book.com> writes:
>
>    Kristin> Does anyone see any issues with restricting TCP/53 on a
>    Kristin> firewall in front of your DNS server?  There would be no
>    Kristin> legitimate query that would warrant an answer larger than
>    Kristin> 512 bytes.  Zone transfers are done internally amongst
>    Kristin> machines behind the firewall.
>
>    Kristin> I've seen postings that say it is not wise to do, but I
>    Kristin> cannot see any legitimate reasons not to.
>
>Well I cannot see any legitimate reasons to block DNS service over
>TCP. You cannot expect the rest of the internet to comply with your
>abitrary and unilateral action like this. [What do you hope to achieve
>by blocking TCP queries? What purpose will this serve?] For one thing,
>you cannot be sure that truncation -- => TCP retries -- will never
>happen. 

If you control the content of the domains on the server, sure you can.  You
can make sure that no name has so many records that it will require such a
large response.

>	 For another, some clients use TCP by default. Here's an
>extract from the man page for sethostent(), which some applications
>like netstat use as a precursor to hostname or address lookups:

>     Sethostent() may be used to request the use of a connected TCP socket for
>     queries.  If the stayopen flag is non-zero, this sets the option to send
>     all queries to the name server using TCP and to retain the connection af-
>     ter each call to gethostbyname() or gethostbyaddr().

I think the XXXhostent() functions query NIS, not DNS.

Also, even if this affects DNS, it will only be the connection to the local
caching server, not the connections from that server to the remote
authoritative servers.

Face it, there are an enormous number of sites that have firewalls blocking
TCP port 53.  It almost never causes problems, because use of TCP for
anything other than zone transfers is extremely rare.  Yes, it's a
violation of the letter of the protocol, but in practice it has little
impact.

Some of the reasons I imagine why sites like to do it:

1) General security policy: prohibit anything that isn't absolutely
   necessary.

2) Old habits: early versions of BIND didn't have zone transfer access
   lists (I'm not sure when xfrnets came along).

3) Since TCP is used in things like SYN-flood attacks, they like to block
   TCP whenever possible.

4) TCP connections use up system resources.  Someone could just do
   "telnet <server> 53" thousands of times, and leave them all hanging.

5) Misinformation/ignorance: they think that ordinary DNS queries only use
   UDP.

All that having been said, *we* have an application that uses TCP for
ordinary queries.  When a customer requests that we implement secondary DNS
for a domain, we add it to our DNS database, but set a flag that keeps it
from being put on our slave servers.  We have a cron job that tests all the
domains with this flag set, to see if the master server is responding
authoritatively.  It uses TCP for this test, to ensure that the site isn't
blocking it.  Once upon a time we used the same machine for slave DNS as
for running cron jobs (in those days it was our all-purpose timesharing
system); nowadays they're different machines, and the script occasionally
runs into problems because the customer is only allowing TCP from our slave
server, not the cron job system (we can update the flag manually when we
notice this).

-- 
Barry Margolin, barmar at genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.