RE: [squid-users] why is the UDP port for DNS queries kept "open"?

Are your NICs PCI-based? If so, I believe they all behave as a single unit
(ie. any card can answer to any address defined in ifconfig), so attempting
to block by interface doesn't have any effect. I've had the same trouble
with ipchains/iptables.

If you are really worried about the security of having port 53 open, I
suggest you move your DNS onto a dedicated server in your DMZ (ie. on your
perimeter network, if you have one, otherwise outside your firewall/proxy,
connected directly to the internet). DNS will not work if you do not allow
udp and tcp packets to/from port 53. If your server is only a caching server
for internal queries, you can block tcp connections (SYN packets) coming in
to port 53, which prevents some nasties.

When I was setting up our firewall I was also advised to stop incoming ICMP
redirect packets (type 5 I believe), as these can also be sent by people who
are trying to play silly buggers with your DNS.

Hope it helps

Winston Gutkowski

-----Original Message-----
From: Steve Bremer [mailto:steveb@nebcoinc.com]
Sent: Monday, March 18, 2002 8:00
To: squid-users@squid-cache.org
Subject: Re: [squid-users] why is the UDP port for DNS queries kept
"open"?

I am also curious about this.

If it's not possible to change this, is it possible to limit which
interface that the internal DNS resolver binds to? I've tried
udp_incoming_address, but it didn't prevent it from binding to all
interfaces.

Steve

On 18 Mar 2002, at 16:57, David Banz wrote:

> Hello!
>
> I am using Squid 2.3stable4 (configures so that Squid does DNS lookups
> itself), and I was wondering why the UDP port used by Squid for this
purpose
> is constantly kept "open" until Squid is shut down.
> Wouldn't it be safer to use a separate UDP port for each new DNS query,
which
> is closed after the query has been answered or a timeout has occurred?
> Personally, I don't like the idea of having a port accepting incomming
data
> all the time, which I cannot hide behind a firewall.
> (Sorry if my terminology might be a bit incorrect, but I hope you still
get
> the idea...)
>
> --
> David Banz
Received on Mon Mar 18 2002 - 12:04:49 MST