This best practice guide builds on Microsoft's TechNet guide, but is appropriate to all networks, including non-Windows systems.
Most organisations require some services to be hosted outside of their LAN whilst other services are hosted within the LAN on local servers. Furthermore, some of the locally hosted services may need to also be accessible from outside of the network. To give an example, consider the following three services:
- A public-facing web site is on an external server that has a public IP address.
- An email system is hosted locally and has an internal (RFC 1918) IP address. However, this service is also accessible to users on the Internet through a port forward on the organisation's internet router.
- An intranet web site is hosted locally and has an internal (RFC 1918) IP address. This service is only accessible to users within the LAN.
It is desirable for the users to always be able to access the web site and email system using the same addresses, without having to consider whether they are currently connected to the organisation's LAN or not.
The current recommended best practice is to put internally hosted services on a subdomain of the organisation's domain. For internally hosted services that are only accessible internally, they are only published by the internal DNS server, whilst internally hosted services that are also accessible from the Internet are also published by the external server. It may also be desirable to add a CNAME to the main domain for externally accessible services in order to hide the subdomain from view.
So for this example, the DNS records might look like:
|External DNS server|
|Internal DNS server|
In this example, everyone can access www.example.com on its public IP address, and if that address changes only the external DNS needs to be changed. Similarly, everyone can access mail.example.com, with external users going to its public IP address and internal users going to its internal IP address. Only internal users will be able to access intranet.int.example.com.
In the event of a temporary internet outage, users within the LAN will be unable to access mail.example.com, since the CNAME record is hosted on the (unreachable) external DNS server, even though the service itself is hosted on the LAN. It is a good idea to set the internal DNS server to be a slave for the example.com domain, so that no external lookups would be required. The external name servers would need to be configured to allow the internal DNS server to perform the zone transfer.
If you have more than one autonomous LAN, it is a good idea to use a separate subdomain for each. For example, if you have a number of geographically separated sites with no interconnectivity.
There are some other options, but these are not recommended. Here's a brief description of them, and some of their problems.
Using your main domain internally
You can use the same name for the internal domain and the external domain. However, this creates name resolution problems because it introduces DNS names that are not unique. This also requires additional configuration, as all of the DNS records for the externally hosted services would need to be duplicated and kept up to date on the internal server. This introduces an obvious management overhead, and it is not always immediately apparent if one of the servers is out of date.
Using a different domain internally
This requires that you register, pay for, and maintain two separate domains. Consideration would have to be given to the fact that the internal domain may still need to be able to receive external email in order to complete domain verification processes to order X.509 certificates, etc. and therefore requires a slightly more complex configuration. There may also be some ongoing temptation to place external services on the internal domain, which would further complicate the configuration (see "Using you main domain internally" above).
Using an unallocated domain, such as .local
An increasing number of systems require you to use a fully qualified domain which you own, even if they are not externally accessible. For example, it is not possible to buy an X.509 certificate for an unqualified domain, and therefore web browsers and other software may produce "untrusted certificate" warnings or simply refuse to work altogether.
Additionally, as the domain has not been officially allocated, there is no way to know whether it will become allocated for some purpose in the future. For example, the .local domain has been reserved by RFC 6762 for use with multicast DNS, utilised by Apple's Bonjour software. Organisations are able to apply for top level domains, and if one of these conflicts with the domain you have chosen, your would need to change your infrastructure.