What is Split-Brain,
Split-Horizon, Split-DNS
Split-Brain DNS, Split-Horizon DNS, or Split DNS are terms
used to describe when two zones for the same domain are created, one to be used
by the internal network, the other used by the external network (usually the
Internet). I prefer the term "Split DNS" so we will just continue
with that one.
A Split DNS infrastructure is used to direct internal hosts
to an internal domain name server for name resolution and external hosts to an
external domain name server for name resolution. This type of DNS configuration
is very common in networks that have established an internal Active Directory
domain name which is the same as the public external domain name. Let's
begin by taking a look at an example where Split DNS is not used
.
Non-Split DNS
This diagram depicts a network design with only one DNS
infrastructure which is being hosted on the internal network to service both
internal and external requests. While this design will work technically,
it may not be appropriate for the business due to security and other concerns.
Here are some issues and concerns that may need to be addressed by
implementing a Split DNS design.
The internal DNS zone is exposed to Internet users. An
Internet user can resolve ALL internal host names.
One or more internal servers are exposed to the Internet.
This can lead to exposing data due to security vulnerabilities in other
services running on the servers.
If the organization has an Internet and intranet web site,
name resolution for the web site using one host name is extremely complex
without additional components. For instance, the URL, http://corp.net,
would point to the same resource even though there would be an intranet and
Internet web site established.
Split DNS
This second example depicts two sets of DNS systems. One
pair of DNS servers are located on the intranet, while another pair of DNS
servers are located on the DMZ servicing the Internet. In a Split DNS
design, these two sets of DNS groups DO NOT replicate the corp.net
zone between them.
Each set of DNS servers hold a PRIMARY/SECONDARY zone for
corp.net. This design mitigates each of the concerns listed above.
However, it does introduce a problem for intranet users, related to name
resolution. What if the Internet DNS zone has a host name called FTP.CORP.NET
and an intranet user needs to get to that resource from within the network?
Well, if this host name is only published in the Internet zone, the
intranet user will NOT be able to resolve the host name. This is because
the intranet DNS servers do not have this record in their zone. The intranet
DNS servers will not attempt to resolve this host name using root hints,
forwarders, or any other DNS servers on the Internet, even though the answer to
the query can be resolved by the Internet DNS servers located in the DMZ.
The reason is because the intranet DNS servers host an AUTHORITATIVE zone
for corp.net. From their perspective, if they do not have the
record, there is no reason to go anywhere else looking for an answer, since the
intranet DNS servers "own" the zone. So how can this be resolved?
Simply create a record on the intranet DNS servers for the host name
"FTP" in the corp.net zone, and point that record to the Internet
resource.
Now that the same record is hosted in both sets of DNS
infrastructures, intranet and Internet users will be able to access the same
resource using the same host name. Keep in mind that if the IP of the FTP
record ever changes, it will need to be updated on the Internet and intranet
DNS servers independently.