Domain Name System (DNS) has a bad reputation for always being at fault if there are any issues with system connectivity and availability. This critical service translates "friendly" system names to network IP addresses, much like looking up a physical address or phone number in a phone book, by using the person's name. We use a system to manage this, so we don't need to keep and update this information on every requesting device. Add a hybrid environment into the mix and it becomes a little more complicated. How do you make sure that the phone book has entries for both your on-premises systems and those hosted in Azure, and how are they both updated?
The hybrid reference architecture "Design a hybrid Domain Name System solution with Azure" helps you design an architecture that can handle both environments. It also covers some common considerations for: - scalability - availability - manageability - security - DevOps - and cost.
I really like how this article captures some key components. Azure Bastion is included, for secure remote access from a public internet connection without having RDP ports open. It also splits Azure into one connected and one disconnected subscription, depending on whether the Azure resources need connectivity back to on-premises resources or not.
The article explains recommendations for: Extending AD DS to Azure - Using Active Directory Integrated DNS zones to host records for both on-premises and Azure workloads. Split-brain DNS - Enabling users to resolve a system name to the relevant Application Gateway public IP address or an internal load balancer address, depending on where their request originates from. Using private DNS zones for a private link - Resolving systems names to the IP address of the load balancer, for Azure systems in the same subscription, via Azure DNS private DNS zones. Autoregistration - Enabling the autoregistration of virtual machines, when configuring a VNet link with a private DNS zone, to remove the need to do this manually when new VMs are provisioned.