Currently, I am having a similar issue with DNS resolution.
We have set a precedent, to have on our public network, a server named
server.com. Previously, all servers in that subnet were named server.org.
Our internal DNS is set to resolved to .org, but not .com. Further, if
somebody external, on the internet, connects to the public network, there is
no issue, the IP and FQDN is resolved. But our internal clients, cannot
resolved the FQDN, but can via IP. Ironic considering this is our public
network, which is available to the public, but not to us. And to make
matters worse, sometimes it is resolved.
I have noticed that port 53 is fine for communication, but also, some of the
internal DNS servers, when attempting to DNS queries outside use port 4587,
5432, and countless others.
What do you make of this? Of course, they blame the firewall, but I tell
them, port 53 outbound is open.
-----Original Message-----
From: Ben Nagy [mailto:[EMAIL PROTECTED]]
Sent: August 9, 2000 9:09 PM
To: 'Johnson, Carl'; [EMAIL PROTECTED]
Subject: RE: Split DNS
> -----Original Message-----
> From: Johnson, Carl [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, 10 August 2000 3:23 AM
> To: [EMAIL PROTECTED]
> Subject: Split DNS
>
>
> This doesn't directly pertain to firewalls, but it
> definitely is an indirect firewall issue so I figured
> I would ask...
>
> When doing NAT on a firewall, the common problem is
> DNS. Internally DNS needs to return a private IP
> address while continuing to provide the NAT'd public
> IP address to the Internet. This is "split DNS"
> (also known as "split brain" or "split horizon").
Split DNS and Split-brain BNS I'll buy - not split horizon though. That's a
"routing thing".[1]
>
> There seems to be a limitation with split DNS though.
> Let's say we have the domain xyz.com.
>
> Ideally the private DNS server would return private
> IP addresses for its xyz.com entries. Anything else
> for xyz.com or external domains it would forward to
> the public DNS server.
>
> The limitation is that it doesn't seem to be that
> simple -- the private DNS server can't just have
> private entries. It must also have all of the public
> entries for xyz.com. That means that the public &
> private DNS servers have overlapping entries. This
> is more of a headache to administer.
Uh...why?
>
> Does anyone know if this is a valid limitation? Our
> DNS administrator can see no way around it and I don't
> know enough about DNS to know otherwise.
>
> If there was DNS software out there that could return
> an IP address based on the source IP of the request, that
> would be PERFECT. Does such a product exist?
You could fake one up, but it would be a horrible kluge and I'm not even
going there - why would you _want_ such a product?
Okay. I _suspect_ that you're missing something. Think of it like this - you
have two kinds of servers, right? Public ones, which are outside the NAT
perimeter (In the DMZ, usually) and private ones, which are inside the NAT
perimeter.
The Inside DNS server gives you the real story - return private addresses
for private servers and public addresses for public servers. Basically, the
DNS on the inside server is _accurate_.
The Outside DNS server gives you ONLY addresses for public servers. It
contains no private data at all. It's the sanitised view of your network for
outsiders to see. External DNS doesn't usually change very often.
Whenever you change an _external_ record, add a server etc etc you need to
update two DNS servers. That's life.
>
> Thanks,
> Carl
> -
I'm a bit puzzled as to exactly what limitation you're seeing here. Maybe
you could clarify a little?
Cheers,
[1] FYI - split horizon is a routing concept whereby no routing updates are
sent back out of the interface they were received on. This helps prevent
routing loops in some topologies. If you want any more info than that I'm
sure a simple websearch will work.
--
Ben Nagy
Network Consultant, Volante Solutions
PGP Key ID: 0x1A86E304 Mobile: +61 414 411 520
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
