Finally, local DNS resolution is a necessity to ensure Microsoft can connect your clients to resources based on their location. Many cloud services use this method, for example, we currently use Geo DNS for Exchange Online to connect your clients to the nearest front-end server for the service. I’ve covered this particular usage in more detail in a separate blog post here.
The diagram below covers this succinctly, showing how a user with an Exchange mailbox in the NAM region, when travelling in EMEA will hit the EMEA front end servers due to the DNS call for outlook.office365.com being completed in Europe.
In short, DNS resolution should be performed local to the network egress (normally the local ISP used is a good choice) which means that the mapping of users to front end servers is accurate for the services which use this method at any point in time. If you use a local egress, perform DNS locally there, if you use a cloud proxy, perform DNS at the proxy location, if your egress is in a different region to the user (not recommended) then the DNS resolution should be where that egress is.
If this mapping is not done, there is a risk of performance issues due to the active endpoint being where the DNS resolution was done, not where the user/egress is.
To summarize, getting your Office 365 traffic, quickly, and unhindered to Microsoft’s global network will allow Microsoft to optimize at the edge, direct you to local endpoints where possible, on a network designed to get you to your data as quickly as possible, reaching that north star of Cloud services which perform as if they are on-premises. This often requires a rethink and redesign of the old internet access method towards a more modern approach to connect you to your cloud services. I’ll aim to update this document with a link to the verbose guidance we’re working on as soon as it’s ready but in the meanwhile, I hope this post was helpful.