Split-Brain DNS

  • Thread starter Thread starter William Stacey
  • Start date Start date
W

William Stacey

Depends. You can have an SMTP reply sit in the DMZ with a public IP that
forwards to your internal mail server behind your firewall. Many good
router can smtp relay to so you don't need another. Normally you also have
a NAT on your router. So any public IPs that need to point "inside" will be
pointed at a public IP on the router that gets NAT'd to an internal IP.
hth.
--wjs
 
I have a question about the practical details of split-brain DNS.

If I'm understanding correctly, you set up two servers, one inside the
firewall to serve the requests of internal clients and one outside to serve
the requests of external clients. The internal server forwards requests to
the external server to resolve requests for resources outside the ones for
which it is authorative.

So in this configuration, where does the web server and mail server sit?
Inside or out? What about the database server for the web site? What I
don't understand is how anything (maybe the web server) on the outside finds
out about where resources are on the inside (like the database server the
web data resides on)?

Any help would be greatly appreciated.
 
First off, thanks for replying and so quickly at that.

Ok, I think I understood what you said, at least in part. I do have a
router that can handle forwarding port 53 to the DNS server in the DMZ and
forward port 25 requests to a mail server inside the firewall. Is that what
you meant? Also, if I had a web server in the DMZ that I wanted to pull
data from a database server inside the firewall, would I just locate the
database server by IP? Or would I set up a host entry for it on the
internal DNS server? And if I did, how would the DNS server in the DMZ know
about it?

Sorry if I'm thick as a brick but I'm fairly new to networking.
 
On the "public" DNS server add a public IP that points to your NAT'd IP for
the SQL server. As you probably only want IIS to have access, you could
just add a hosts file entry on that box. Also make sure only the IIS box
(or what ever) is allowed access to the NAT'd IP.
--wjs
 
j> If I'm understanding correctly, you set up two servers, [...]
j> The internal server forwards requests to the external server [...]

That's one way of setting up "split horizon" DNS service, but not the
best one.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/dns-split-horizon.html>

For far better results, the "external" DNS server should serve your
DNS database content only. It should not provide proxy DNS service
for lookup of the rest of the world's DNS database content. Recursion
should be disabled. Providing promiscuous proxy DNS service is as bad an idea as providing promiscuous proxy HTTP service, or promiscuous
SMTP Relay service.

As such, your "internal" DNS server should either perform query
resolution itself, using root hints, or should forward to another
proxy DNS server closer to the rest of Internet that performs query
resolution. (Your ISP may provide you with proxy DNS service, for
example.)

j> What I don't understand is how anything (maybe the web server)
j> on the outside finds out about where resources are on the
j> inside (like the database server the web data resides on)?

Concepts such as "on the outside" and "on the inside" are too
simplistic and misleading. The fact that a content HTTP server
listens on a publically reachable IP address does not mean that
it is required to see the "public" view of the DNS namespace.
The fact that the rest of Internet uses the "public" view of the
DNS namespace to locate your content HTTP server's IP address
does not mean that your content HTTP server is required to have
that view _itself_.
 
Back
Top