firewall blocking 53

[Pete Ehlke]

On Wed, Aug 07, 2002 at 02:04:22PM -0400, Eric L. Howard wrote:
> 
> At a certain time, now past, Pete Ehlke spake thusly:
> > 
> > On Wed, Aug 07, 2002 at 01:36:22PM -0400, Eric L. Howard wrote:
> > > 
> > > This timeout is something that you can configure in Firewall-1.  Look under
> > > the properties for your rule-set.  40 *seconds* is a long time to wait for
> > > return traffic...
> > > 
> > Most of the DNS is UDP traffic. It's expected that there will sometimes
> > be timeouts. 
> 
> 40 seconds is still a long time to wait for a reply packet.  Whether that
> packet is delivered via UDP or as part of a TCP session...
> 
> So many things could have happened to a packet/session in 40 seconds, that
> the timeout has got to be set somewhere.

I completely agree. *Applications* should set a timeout; named's default
is 30 seconds. And there might be certain paranoid situations in which a
firewall administrator might want to dynamically block random ports that
send datagrams that never get replied to- there are certainly various
badguy applications that are known to communicate via unacknowledged DNS
or ICMP packets, for example. But you've not convinced me that this is a
good thing to be applying to your internal name servers, which due to
the nature of the DNS *will* sometimes emit queries that do not get
responded to.

> 
> > If you've set up Firewall-1 to dynamically block ports on your name
> > server based on the fact that it's sending UDP datagrams that don't get
> > replied to, then you have shot yourself in the foot. Pinning your query
> > source-port won't help at all.
> > The right answer here is "Don't do that".
> 
> Firewall-1 by default is (was?) set to 40 seconds as the UDP timeout.
> Aiding in his ability to nail down the timeout window.  This is not
> necessarily a misconfiguration on anyone's part...
> 
Well, if it cuts off services that are business critical and not meant
to be cut off, then it's a misconfiguration. Full stop.

-P.