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.
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.
This second example (Split DNS) 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 holds 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 hostname called FTP.CORP.NET and an intranet user needs to get to that resource from within the network?
Well, if this hostname is only published in the Internet zone, the intranet user will not be able to resolve the hostname. 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 hostname 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 that 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 hostname “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 hostname. 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.
