Hi, our firewall keeps detecting and rejecting TCP/53 queries.
Does bind by default use TCP/53 and UDP/53? Is there any way to disable
TCP/53, thus enabling UDP/53?

        Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andr...@isc.org

Yes. So does any name server that complies with the DNS protocol. Read
RC1035. Here's an excerpt:

        4.2. Transport

        The Internet supports name server access using TCP [RFC-793] on server
        port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
        port 53 (decimal).

    Tan> Is there any way to disable TCP/53, thus enabling UDP/53?

No. [Not that disabling TCP/53 could somehow automagically enable
UDP/53 anyway.] Name servers are supposed to accept queries on port 53
from both TCP and UDP. That's what the DNS protocol says. Your
firewall is broken. Fix it.

Tan Chun Han/ITNOC/PBB/PBBG <ta...@publicbank.com.my> wrote:

Fix the fw config and the messages will go away.

--
Peter Håkanson        
        IPSec  Sverige      (At the Riverside of Gothenburg, home of Volvo)
           Sorry about my e-mail address, but i'm trying to keep spam out.
           Remove "icke-reklam" and it works.

hi phn, as far as i know, DNS should use UDP/53 only and not TCP, that =
is
why
our FW is configured for UDP, unless there's zone transfers. as for our=

case, this
is only our Internal DNS for it to resolve MX records and www addresses=
.
therefore we don't need TCP/53 for name server resolving.

thanks and regards

p...@icke-reklam.ipsec.nu@isc.org on 21/02/2002 02:26:16 PM

Sent by:  bind-users-bou...@isc.org

To:   comp-protocols-dns-b...@isc.org
cc:

Subject:  Re: Disable TCP/53

Tan Chun Han/ITNOC/PBB/PBBG <ta...@publicbank.com.my> wrote:

Fix the fw config and the messages will go away.

--
Peter H=E5kanson
        IPSec  Sverige      (At the Riverside of Gothenburg, home of Vo=
lvo)
           Sorry about my e-mail address, but i'm trying to keep spam o=
ut.
        Remove "icke-reklam" and it works.

=

George Young / G-L Data, Inc / Morristown, NJ / 732.433.7900

At 01:49 AM 2/21/02, Tan Chun Han/ITNOC/PBB/PBBG wrote:

         Danny

Tan Chun Han/ITNOC/PBB/PBBG <ta...@publicbank.com.my> wrote:

So go back and fix that FW, it's broken as it's configured now.

peter h

--
Joe Yao                         j...@center.osis.gov - Joseph S. D. Yao
OSIS Center Systems Support                                     EMT-B
-----------------------------------------------------------------------
   This message is not an official statement of OSIS Center policies.

There have been a number of responses in the line of "your firewall is
broken -- fix it".  This is not necessarily the case. DNS uses TCP for two
reasons.  The first is zone transfers, the second is to return responses to
queries that are too large to fit in a UDP packet.

Regarding zone transfers, you should only allow authorized external
secondary DNS servers to do a zone transfer from your server.  Two security
settings can be applied here.  On the DNS server, you can specify a list of
servers authorized to pull zone files.  If you have a firewall of some sort,
you can also restrict access to TCP/53 to your DNS server to the same list
of authorized secondaries.  Restricting access to TCP/53 on the firewall
will interfere with the ability to use TCP for large query response but most
people don't have DNS records so complex or numerous that the responses
don't fit in UDP response packets.

Dave Goldsmith

What are you so paranoid about? We've had zone-transfers open for years and not
once have we suffered from an AXFR DoS attack. Is all the maintenance of those
firewall rules buying your organization any real security, or is it just
feeding some PHB's gnawing case of paranoia? How many times have you had zone
transfers *break* because an off-site slave re-addressed their server and
forget to tell you about it?

Oh, and what do you plan to *if* some day your DNS maintainers decide to create
an RRset which will cause responses to overflow 512 bytes? Will you get enough
advance notice so that you can modify your firewall rules accordingly, or will
things just break unexpectedly?

If you're *that* paranoid about zone transfers, then use TSIG to restrict
access. But leave TCP/53 open on the firewalls. That's the only practical
option, IMO.

- Kevin

While this is true it does not mean that it's OK to block or refuse
TCP queries to port 53. Some applications that make lots of lookups --
like netstat -- can use a TCP connection for their queries.

Remember that one of the big irons once had a version of their un*x that
actually defaulted to TCP. Blocking TCP would prevent all of these
from ever asking such a nameserver.

And it's no option either, it's specifially required
( rfc1123 6.1.3.2  Transport Protocols)

If you want (or are required) to be very paranoid about this, the
obvious thing to do is to contract with someone outside your firewall to
provide nameservice for you.  If the only reason for not doing this is
that you want to be able to update your zones without going through a
third party, a technique which seems to work well is to contract for
secondary nameservice only and run a hidden primary nameserver inside
your firewall with the firewall configured to block all incoming traffic
for port 53 (both TCP and UDP) unless it is between the outside
secondary nameservers and your hidden primary nameserver.  [To allow
blocking all other UDP/53 traffic you must also configure all systems
inside your firewall to send DNS requests to a small number of
nameservers inside the firewall, configure those nameservers to forward
all requests for which they are not authoritative to some small number
of nameservers outside the firewall (here again, you'll need to contract
with someone), and configure the firewall to also allow incoming UDP
port 53 traffic from those outside namservers to the inside ones.]  This
sounds complicated but (with the possible exception of contract issues)
is actually pretty straightforward.  

        Dave

--
Dave Anderson
<d...@daveanderson.com>

dave,

what you've mentioned was our exact config.
Another thing that i want to stress is, we are not being "paraniod" about
disabling TCP53!
Couldn't find an option to do that, so i posted it to the newsgroups.

Anyhow, thank you all for your valuable comments!

regards

d...@daveanderson.com@isc.org on 25/02/2002 11:34:44 PM

Please respond to d...@daveanderson.com

Sent by:  bind-users-bou...@isc.org

To:   comp-protocols-dns-b...@isc.org
cc:

Subject:  Re: Disable TCP/53

In <a51lf7$...@pub3.rc.vix.com>, "Tan Chun Han/ITNOC/PBB/PBBG"

If you want (or are required) to be very paranoid about this, the
obvious thing to do is to contract with someone outside your firewall to
provide nameservice for you.  If the only reason for not doing this is
that you want to be able to update your zones without going through a
third party, a technique which seems to work well is to contract for
secondary nameservice only and run a hidden primary nameserver inside
your firewall with the firewall configured to block all incoming traffic
for port 53 (both TCP and UDP) unless it is between the outside
secondary nameservers and your hidden primary nameserver.  [To allow
blocking all other UDP/53 traffic you must also configure all systems
inside your firewall to send DNS requests to a small number of
nameservers inside the firewall, configure those nameservers to forward
all requests for which they are not authoritative to some small number
of nameservers outside the firewall (here again, you'll need to contract
with someone), and configure the firewall to also allow incoming UDP
port 53 traffic from those outside namservers to the inside ones.]  This
sounds complicated but (with the possible exception of contract issues)
is actually pretty straightforward.

        Dave

--
Dave Anderson
<d...@daveanderson.com>