Plan the DNS zones for a custom domain

5 minutes

A publicly available DNS zone setup is critical during the Microsoft 365 deployment for organizations that want to use custom domains, whether in a hybrid deployment or a cloud-only environment. When setting up Microsoft 365 with custom domains, the Domain Name System (DNS) plays a crucial role in enabling the proper functioning of various services and features, such as email, SharePoint, Teams, and other Microsoft 365 applications. A publicly available DNS zone is necessary to publish the required DNS records that associate your custom domain with the Microsoft 365 services.

There are several reasons why a publicly available DNS zone is essential when setting up a custom domain, including:

Domain Verification. During the Microsoft 365 deployment, you must verify ownership of your custom domain. This process typically involves adding a specific TXT record or CNAME record to the DNS zone of your custom domain. The DNS zone must be publicly accessible for the verification process to succeed.
Email Delivery. If you want to use Microsoft 365 for email services with your custom domain, the DNS records must be properly configured. This process includes setting up MX (Mail Exchanger) records that specify the mail servers responsible for accepting email on behalf of your domain. You must publish these MX records in the publicly available DNS zone to ensure proper email delivery.
Autodiscover and Federation. Microsoft 365 relies on autodiscover functionality to configure email clients automatically and establish federation for certain features like single sign-on (SSO). These processes require that you add specific DNS records, such as Autodiscover records and Federation records, to the publicly available DNS zone.
Web Services and Applications. If your organization uses custom web applications or services hosted within Microsoft 365, it's necessary that you properly configure DNS. Doing so includes creating relevant DNS records like CNAME or A records to point your custom domain to the correct web services or applications.

In both hybrid deployments and cloud-only environments, a publicly available DNS zone is crucial because it allows external entities, such as internet users or other services outside your organization's network, to resolve and access the Microsoft 365 services associated with your custom domain.

Important

While the DNS zone must be publicly available, you can still implement security measures, such as Domain Name System Security Extensions (DNSSEC) and access controls, to protect the integrity and confidentiality of your DNS records and domain.

The first part of this training unit focuses on DNS zone planning in a hybrid configuration. While DNS zone planning principles for a cloud-only environment are similar to a hybrid environment, there are some differences, which the final section of this unit examines.

DNS Zone planning in a hybrid deployment

In a hybrid deployment, an organization spreads its infrastructure across both on-premises and cloud environments. In this scenario, DNS zone planning involves considerations that accommodate the coexistence and communication between these environments. The DNS zone planning principles for a hybrid deployment include:

Understand the Hybrid Infrastructure. You must gain a clear understanding of your organization's hybrid infrastructure, including the on-premises network and the cloud environment. You should identify the domain structure, IP addressing scheme, and existing DNS infrastructure in both environments.
Namespace Integration. You must determine how the DNS namespace is integrated between the on-premises and cloud environments. You must decide whether to maintain a single namespace or use separate namespaces for each environment. Common approaches include subdomains, such as "cloud.example.com" for the cloud environment, and "internal.example.com" for the on-premises environment.
DNS Forwarding. You must configure DNS forwarding between the on-premises DNS servers and the cloud DNS service. DNS forwarding enables resolution of DNS queries that aren't locally authoritative to be forwarded to the appropriate DNS service for resolution. This process ensures seamless name resolution across the hybrid infrastructure.
Split DNS. Organizations should consider implementing split DNS to handle name resolution differently for internal and external users. This approach enables internal users to resolve internal resources using internal DNS servers while external users resolve the same resources using public DNS servers. Split DNS provides security and control over DNS resolution for internal resources.
DNS Synchronization. You must implement DNS synchronization mechanisms between the on-premises DNS infrastructure and the cloud DNS service. Doing so ensures that changes made in one environment, such as adding or modifying DNS records, are propagated to the other environment to maintain consistency and synchronization.
Service Discovery. You should consider the service discovery mechanisms required for hybrid deployments. These mechanisms include DNS-based service discovery solutions like SRV (Service) records or specialized tools like Azure Service Discovery. These mechanisms enable applications and services to dynamically discover and communicate with each other across the hybrid infrastructure.
Security and Compliance. Organizations should implement security measures, such as firewalls, Domain Name System Security Extensions (DNSSEC), and access controls across both the on-premises and cloud DNS environments. You should comply with the security policies and regulations governing your organization's hybrid infrastructure.
Monitoring and Troubleshooting. You should set up monitoring and troubleshooting capabilities for DNS resolution in both environments. These features should include monitoring DNS traffic, latency, and health, as well as having logging and alerting mechanisms in place to identify and address any DNS-related issues promptly.

Remember, the specific DNS zone planning principles in a hybrid deployment may vary depending on the chosen DNS solutions, network architecture, and organizational requirements. It's important that you consult the documentation provided by your DNS providers and any relevant hybrid deployment guides for detailed instructions tailored to your specific environment.

DNS zone planning for a custom domain

An organization can prove that it owns the DNS zone if it's able to edit records within that zone. When an organization owns the DNS zone, the Microsoft 365 setup wizard can create the tenant with the organization’s custom domain, such as adatum.com.

Furthermore, during the setup, the Microsoft 365 setup wizard instructs organizations on which DNS records they must add to the public DNS zone. Once the organization configures the DNS zone per these instructions, client software such as Outlook or the Skype for Business Client use auto discover services and resolve custom domain names with the IP addresses of Microsoft 365 servers. This process enables an organization’s client computers to connect to Microsoft 365 services, such as Exchange Online or Skype for Business Online.

Organizations use internal DNS zones configured on internal DNS servers, so that internal clients can resolve computer names and services. Organizations also use external, public DNS zones configured on Internet‑accessible DNS servers so that clients located on the Internet can resolve computer names and services. A couple of options are available for hosting the DNS zone for a custom domain:

Have a third-party provider, such as GoDaddy, host the DNS zone for the custom domain. This scenario enables an organization to manage DNS through a web portal. It still needs a way to handle internal name resolution if it uses the name for resources that are on-premises. Companies usually choose to host an internal DNS zone for the domain.
Host the DNS zone on-premises by using or deploying DNS servers. This scenario enables an organization to have DNS servers in the perimeter network so that internet users can resolve the organization's internet-facing domain resources. You can also use internal DNS servers to handle name resolution for resources on the local area network.

When an organization plans the DNS zones for a custom domain, it can choose between the following scenarios:

The internal DNS zones and external DNS zones have different names.
The internal DNS zones and external DNS zones have the same name. This scenario is referred to as "split brain DNS," or "split DNS" for short.

Internal DNS zones and external DNS zones have different names

Companies in this scenario can set up their own internal DNS for their internal domain, such as adatum.local. They can then use a DNS forwarder on the internal DNS servers to redirect to an external name server the name resolution requests for external domains.

For example, a request for mail.adatum.local would be redirected to an internal IP address, such as 192.168.20.10. Conversely, a request for mail.adatum.com may go to 131.107.43.19, which is the company’s external IP address for that host name.

Internal clients that connect to Microsoft 365 services from the internal network submit resolution requests to the local DNS servers. Then, a local DNS server forwards the client’s request to the external DNS server. The DNS server then resolves the request and returns the answer to the company’s internal DNS server. Lastly, the local DNS server forwards the resolved request to internal clients.

Internal DNS zones and external DNS zones have the same name (referred to as split brain DNS or "split DNS" for short)

Split DNS is a configuration in which the internal and external DNS environments provide different IP addresses to requests for the same host name. The IP address provided depends on which server is used for name resolution.

For example, if a request for mail.adatum.com comes from inside the adatum.com network, the address returned may be 192.168.20.10 (a private IP address). However, if a user directly connected to the Internet made the same request for mail.adatum.com, the IP address returned may be 131.107.43.19 (a public IP address). This configuration is achieved by creating a zone on the internal DNS server for adatum.com.

When a client on the internal network makes a request for mail.adatum.com, the internal DNS server responds with the IP address for that host. In doing so, it uses the A (Address) or CNAME (common name) records that the server maintains for that zone. There's no requirement to forward on the name resolution request to the external DNS servers. However, external clients who try to contact mail.adatum.com receive a response from the external DNS server that's authoritative for that zone.

Internal clients that connect to Microsoft 365 services from the internal network submit resolution requests to the local DNS servers. For a local DNS server to resolve the request to Microsoft 365 services, the local DNS zones and external DNS zones should both be configured with the same records requested by the Microsoft 365 setup wizard. Once both the internal and external DNS zones are configured with the same records, clients can connect to Microsoft 365 services from either inside the company or through the internet.

DNS zone planning when moving an entire tenant to the cloud

The prior sections in this unit focused on planning internal DNS zones in a hybrid configuration. Organizations must also plan for DNS zones when they move their entire tenant to the cloud. In the scenario, there are several key considerations that organizations must keep in mind. The principles for DNS zone planning in a cloud-only environment are similar to the principles for a hybrid environment, with some other aspects to address. The following list introduces those key considerations:

Understand DNS Zones. A DNS zone is a portion of the DNS namespace that a specific organization or entity manages. It typically represents a domain or a subdomain. Before planning DNS zones, ensure you have a clear understanding of your organization's domain structure and requirements.
Choose a DNS Provider. In a cloud-only environment, you have the flexibility to choose a DNS provider that best suits your organization's needs. Microsoft Azure offers Azure DNS, a scalable and highly available DNS hosting service. Alternatively, you can opt for other DNS providers like Amazon Route 53 or Google Cloud DNS.
DNS Zone Hierarchy. You should establish a logical hierarchy for your DNS zones based on your domain structure. This hierarchy typically aligns with your organization's Active Directory (AD) structure, but it can also be customized based on your specific requirements. You should consider creating separate DNS zones for different domains, subdomains, or geographic locations to manage them efficiently.
DNS Zone Design. You should design your DNS zones based on the services and resources hosted in the cloud. You should consider creating separate DNS zones for various cloud services like web applications, databases, virtual machines, and other resources. This segregation helps in efficient management, security, and delegation of DNS records.
DNS Record Types. You should identify the different types of DNS records required for your cloud-based services. Some common record types include:
- A records. Maps a domain/subdomain to an IPv4 address.
- AAAA records. Maps a domain/subdomain to an IPv6 address.
- CNAME records. Creates an alias for a domain/subdomain, redirecting it to another domain/subdomain.
- MX records. Specifies mail servers responsible for accepting email on behalf of a domain.
- TXT records. Allows you to add additional information or verification records.
DNS Zone Delegation. If you have multiple DNS zones and you want to delegate control to different teams or departments, you must configure zone delegation accordingly. Doing so allows different teams to manage their own DNS records within their delegated zone.
DNS Security. You must ensure that proper security measures are in place to protect your DNS zones. You should implement Domain Name System Security Extensions (DNSSEC) to add an extra layer of security to your DNS infrastructure and prevent DNS-related attacks.
Monitoring and Maintenance. You should regularly monitor and maintain your DNS zones to ensure their integrity and performance. You should configure appropriate monitoring tools to track DNS resolution, latency, and overall health. It's essential that you stay updated with any changes or updates from your DNS provider to ensure compatibility and security.

While these steps provide a general guideline, it's essential that organizations consider their specific requirements and consult the documentation provided by their chosen DNS provider for detailed instructions on zone planning in a cloud-only environment.

Knowledge check

Choose the best response for the following question.