Azure-docs: Virtual Network Gateway + VNET + Azure Provided (Default) DNS

[rocketraman]

This page needs some discussion of the Virtual Network Gateway + VNET configured with Azure-provided DNS (which is the default).

In this situation, the DNS server is the virtual IP 168.63.129.16. This IP is only accessible for name resolution inside a VNET, and this IP is not exposed as a routable IP for the VPN clients (neither site-to-site nor point-to-site). In this configuration, using a customer-managed DNS forwarder inside the VNET seems to be required, at least for now.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: a7b1b215-0434-145b-cd11-95d0f32bc015
• Version Independent ID: d328a868-a151-1985-2b62-f3884f7ad76c
• Content: Name resolution for resources in Azure virtual networks
• Content Source: articles/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances.md
• Service: virtual-network
• GitHub Login: @rohinkoul
• Microsoft Alias: rohink

[SubhashVasarapu-MSFT]

@rocketraman, Thanks for your feedback. We are looking into this query and will update you as soon as possible.

[SubhashVasarapu-MSFT]

@rocketraman, Appreciate your patience, as you said the virtual IP 168.63.129.16 is only accessible for name resolution inside a VNET. For the name resolution between VMs in different virtual networks, you must go with either,
1.Azure DNS private zone
2.Customer-managed DNS servers (which has been used in the shown figure)
To access the recursive resolve in azure is provided via the virtual IP 168.63.129.16.
We are closing this issue for now. If there are further questions regarding this matter, please reply and we will gladly continue the discussion.

[rocketraman]

For the name resolution between VMs in different virtual networks, you must go with either,

@SubhashVasarapu-MSFT I believe you misunderstood the point of the issue. The gap in the docs is not related to VMs in different virtual networks. It is related to name resolution between a VPN client and a virtual network.

For the name resolution between VMs in different virtual networks, you must go with either,
1.Azure DNS private zone
2.Customer-managed DNS servers (which has been used in the shown figure)

Exactly my point. In this situation of a VPN client and a virtual network, option 1 does not solve the problem. Even with an Azure DNS private zone, name resolution does not work for a VPN client, because the only way to access the DNS private zone is via the virtual IP, which is not accessible from the VPN client network. Therefore, the only option in this case (currently) is option 2.

Does it make sense now what the gaps in the docs is?

[rocketraman]

There should be an additional scenario listed, which is:

Name resolution between point-to-site or site-to-site VPN clients using Azure DNS Private Zones.

and the solution would be something like:

Customer-managed forwarding DNS servers defined for the virtual network hosting the VPN gateway. See Name resolution using your own DNS server.