Intro

I’ve seen a practice implemented where DNS was locked down by restricting DNS servers from acting in a recursive manner by not using forwarders or root hints.  This is also known as a hardcoded configuration where typically a whitelist of approved DNS records is configured.  If those DNS server/s don’t have record information for a client DNS lookup, a failed result is returned.  This type of setup can cause headaches for O365 customers that have a DNS implementation like the one described above. 

More Details

Microsoft does publish a list of Office 365 endpoints across each workload (SharePoint Online, Exchange Online, etc..).   The endpoints include IP Addresses, DNS domain names, and URLs.  Assuming you configure DNS in the manner above using the published endpoints, that’s not enough.   This is because Microsoft utilizes DNS chaining meaning there are intermediary CNAME records that aren’t on the list of published endpoints.  

Basics of DNS Chaining

Before going any further, I should provide some details around DNS chaining.   Let’s take a very simplistic approach of using a local Windows DNS Server.  In my setup, my users are accessing a website marketing.contoso.com. 

Above, I have CNAME for marketing that points to CNAME middleman and that forwards to my A record myRandomness.contoso.com.  A response of 192.168.2.51 is returned to the client.  The client can then connect to 192.168.2.51 and perform an http get for the page.

Question:  How can I ensure I’m resolving the final A record?   

Answer:  I like using either Resolve-DnsName PowerShell cmdlet or nslookup.  Using both a successful attempt looks like:

Using Resolve-DNSname

In the above example, you can see the resolution is in order and finally I retreive the IP Address back. 

Using NSLookup

In this example, you can see FQDN of the DNS server handling the request followed by the A record and the aliases involved in the chain.  Within Office 365, this is obviously more complex with multiple servers involved and often larger DNS Chains.  

Question:  What does a typical DNS chain look like accessing a SharePoint site in Office 365?

Answer: 

In the screenshot above, my SharePoint site is m365x475871.sharepoint.com.   The chain starts with the domain name I specified.  Next, we have two intermediary CNAME records before finally getting an A record response with an IP address. 

Conclusion

The two intermediary CNAME records in my example could easily change for a variety of reasons.  The most common reason is a failover for maintenance purposes.  We recommended not to hardcode these intermediary CNAME records as it’s not supported.   In fact, Microsoft makes it clear that this isn’t a supported configuration and intermediary records change without any advance notice required.

From here:

Microsoft does not publish the intermediary CNAME records, they are subject to change at any time, and you should not need to configure them as allowed in your proxy server.

Hard-coded configurations or whitelisting based on indirect Office 365 FQDNs is not recommended, not supported by Microsoft, and is known to cause customer connectivity issues

Thank You,

Russ Maxwell
Premier Field Engineer @Microsoft