Microsoft DNS Server has a feature where you can set up forwarders that forward DNS queries that the server can’t answer to answer server. In most cases, probably 99% of the time that people set up global forwarders, the global forwarders aren’t needed. This is because that when a DNS server can’t satisfy a DNS lookup, it will automatically go to the root DNS servers to satisfy the query.
When the machines are running as virtual machines in the Microsoft Azure cloud, having global forwarders set up and pointing to external DNS servers can cause problems. When using private DNS zones within Azure, having them work correctly requires having the DNS server be in Azure, and not having global forwarders set up. When there are global forwarders set up, and the DNS server gets the request for the private zone record it can’t satisfy the request. So it forwards the query to the global forwarders, in the image it uses 4.2.2.2. When 4.2.2.2 gets the request for the private domain it can’t satisfy the request. So 4.2.2.2 sends the request to the DNS server which hosts the records, which is Microsoft’s DNS server.
Microsoft DNS server sees that the server which is requesting the private zone record is 4.2.2.2, and it returns back the public record. The reason for this is that if the Microsoft DNS server gets a request for the private zone name, and the requesting IP address isn’t from a subnet that is granted access to the private zone, it returns the public IP address for the record. If the IP address is from a subnet that is granted access to the private zone, it returns the private link record.
If you aren’t familiar with private DNS zones and how they work with private endpoints, the docs from Microsoft on this feature are online.
If you have your infrastructure in Microsoft Azure and you are looking for some assistance in tuning or managing your Microsoft Azure platform, the team at Denny Cherry & Associates Consulting will be happy to help. Start by contacting our sales team.
Denny