iTechNote

I recently setup a mail server for a company. I was blamed for using the same domain name for internal and external access. I was asked to use a different internal and external domain name instead. The irony is the difference between the domain names is so subtle. For external domain name, I was asked to use example.com and example.com.my for internal domain name.

The reason some people prefer using different names for internal and external domains is a DNS suffix like .corp can not be resolved by external network clients because it is not a publicly available top level domain name. The disadvantage is that this configuration requires you to manage two separate namespaces. Also, using a stand-alone internal domain that is unrelated to your external domain might create confusion for users because the namespaces do not reflect a relationship between resources within and outside of your network. Whatever security advantages that may be gained by this DNS design are mitigated by the complications and user dissatisfaction you’ll encounter when using different domain names for internal and external network resources.

For example, employees must remember two different FQDNs. One of the domain names must be used when they access mail from remote locations and the second domain name is used when users are directly connected to the corporate network. Imagine a scenario in which an IMAP client is setup to access mail from remote locations. When the IMAP client tries to connect to the server using the external FQDN of the mail server within corporate network, the DNS query will fail. The user’s only choice is to setup two profile to check his email, one for external and one for internal use.

The solution to the problem is Split DNS. Many organizations find it desirable to implement a split DNS infrastructure to solve the problem of name resolution for users to move between the corporate network and remote locations.

A split DNS infrastructure occurs when two different DNS servers are configured to be authoritative for the same DNS domain namespace. A DNS server is authoritative for a domain name when it contains Resource Records (RRs), for example, the A, NS, MX, CNAME, SOA RRs, for the domain name in a text-based zone file.

In the split DNS infrastructure, one of these authoritative DNS servers contains RRs for external clients; that is, the zone file used by external network clients contains no RRs used for name resolution on the internal network. The other authoritative DNS server contains RRs for internal network clients; that is, the zone files do not contain RRs that point to the external IP addresses of published resources.