On Thu, 17 Feb 2000, Kent Hundley wrote:

> I have to agree with Peter (who also responded to this), you should be
> using a "split brain" DNS.  One for your inside devices and one for your
> outside devices.  If you use a DNS on the outside only, it can be
> queried and reveal information about your internal IP addressing
> structure that would better be kept secret.  Most organizations use this
> approach.

Bind 8.x supports ACLs on the query list so that people can't do this sort
of thing, and if that doesn't work for you, there is always the PIX alias
command (which I don't trust and won't use.)

-john

> > 
> > If the PIX can't do this then I've got to run 2 set of DNS servers, one pair for
> > the public to use and one pair for my servers to use, or use the hosts file for
> > the servers.
> 
> Yes, and this is recommended (the dual DNS servers, not the hosts
> file).  Take a look at "Building Internet Firewalls" and "DNS and BIND",
> both by O'reilly.  They address this issue specifically.

It was the recommend approach quite a few years ago, but I still uphold
the dual DNS server to prevent things like cache poisioning. 

> > Could Cisco really have made a firewall
> > that causes such problems? 
>
> I suppose its a matter of perspective, but I don't see this as a
> problem.

It's not a problem. It's an implementation issue. 
 
> >Do all firewalls prevent hosts inside from
> > connecting to other hosts inside via their outside addresses?
> 
> 
> Don't know.  There's probably some that allow this, but I don't see a
> lot of value to providing such a solution.  If you want to control
> access between devices, they should reside on different interfaces on a
> firewall.  At a minimum, you should consider using VLAN's, which is
> better than nothing, but not as good as physical separation.  (the PIX
> doesn't support VLAN's)

Well, what's really happening here not the firewall preventing the packet,
the firewall is trying to translate the packet outbound as NAT and it's
not bringing the packet back in. 

Linux does the same thing outbound (but our Cisco 2600 doesn't; how odd.)

-john


-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to