Restricting TCP / 53 on the firewall level

[Jim Reid]

>>>>> "Barry" == Barry Margolin <barmar at genuity.net> writes:

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

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

In theory, perhaps. In reality no. Even if no name "has so many
records", let's not overlook how much data gets stuffed into the
Authority and even the Additional Sections of the replies. Face it,
most people don't have a clue how much data their server sends out in
an answer.

    >> 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().

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

Not necessarily. The version of these functions shipped with BIND only
use the DNS. [No surprises there.] On my BSD box, they *only* query
the DNS. For most systems nowadays these gethost*() calls first
consult another config file to decide if the lookup uses /etc/hosts or
DNS or NIS or some combination of them. The stayopen flag goes back to
the days before NIS and DNS when everyone had huge /etc/hosts files,
so if an application was going to make more than one lookup, it made
sense to hang on to the file descriptor for the already opened file.

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

How could you possibly know that the original poster even has separated
caching-only and authoritative servers and that all stub resolvers only
point at the caching-only servers? Even then, what's to stop the rest
of the world from telling their lookup tools to use TCP to query the
OP's TCP-blocked servers?

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

That may be your experience. But it still doesn't make the practice of
blocking TCP queries right or sensible.