DNS Namespaces Configuration
Applies to: Office 365
Topic Last Modified: 2014-01-06
DNS name resolution across Microsoft and your organization’s namespaces is required for Active Directory authentication and for client access to specific Office 365 services. In order to set up Active Directory trusts, it is necessary for domain controllers in the Microsoft Managed Forest to resolve names in the Customer Forest and vice versa. To fulfill this requirement, Microsoft will request that you provide a list of DNS servers that can resolve your Active Directory domain names and use the list of names to establish conditional forwarders to these DNS servers. Similarly, Microsoft will provide you with a list of DNS servers that can resolve names in the Microsoft Managed Forest and you will need to configure their DNS servers to conditionally forward requests to Microsoft DNS servers.
Depending on which Office 365 services your organization subscribes to, it will be necessary for you to establish conditional forwarders to Microsoft DNS servers to resolve names in additional Microsoft-owned namespaces that are not publicly resolvable via the Internet.
We recommend that you host your DNS solution on reliable hardware that is designed for high availability. In addition, these DNS servers must be geographically distributed and have redundant ingress/egress paths through which the Microsoft DNS servers can forward requests.
Split-horizon DNS—also called split brain DNS—describes a common configuration that allows a single DNS name to be resolved to differing IP addresses depending on the location of the client computer.
Exchange Online requires that customers access the service using names in customer-owned domains. Thus, you must implement split-horizon DNS for the domain name used to access Exchange Online.
We recommend that you choose a domain name for hosting split horizon DNS records related to Exchange Online that is not used by other applications. A common approach is to use a dedicated subdomain of your main domain. For example, if the primary domain of a customer is contoso.com, a subdomain such as o365.contoso.com can be used to host records for accessing online services. The advantage of using a dedicated subdomain is that a customer can make changes to the configuration of the DNS zone for the domain without affecting other applications.
The sections below describe DNS configurations that are not supported with Office 365 dedicated plans networking.
Microsoft does not support trusts to your account domains or forest root domains that use single-label domain (SLD) names. SLDs are DNS names that do not contain a suffix such as .com, .corp, .net, or .org. For example, “contoso” is an SLD and therefore is not supported. However, “contoso.com” and “contoso.local” are not SLDs and therefore are supported.
Although Active Directory and DNS do currently support single-label DNS names, not all Office 365 services support them and therefore they cannot be used. Organizations that use SLD names must rename these domains prior to transitioning to Office 365 services.
Zone transfers are not supported by Microsoft or between Microsoft and DNS servers. This limitation is primarily due to the additional complexity of the bilateral configuration that is necessary to secure zone transfers.
Setting up zone transfers to your DNS servers outside of a Microsoft Managed Forest would require that a full list of your DNS server IP addresses be maintained on the managed DNS servers.
Implement the DNS solution for your organization by completing all the necessary namespace configuration changes required to successfully integrate your network with the Microsoft networks. The work includes, for example, adding forwarders for your specific internal namespaces.
Consult with your organization when you make changes to the DNS configuration.
Forward DNS requests for Microsoft-owned internal namespaces to the defined Microsoft DNS servers.
Provide Microsoft with a list of highly available, geographically-dispersed, internal DNS servers that can resolve all the accessible servers for your organization.
Address implementation of split-horizon (or split-brain) DNS configurations.
Avoid the implementation of single-label domain names and zone transfers.