What to watch out for when setting up Azure DNS Private Resolver

You have the use case of accessing an Azure Key Vault through a private endpoint from your own machine. One solution is to combine Azure VPN Gateway with Azure DNS Private Resolver.

• The VPN Gateway provides the network path to Azure.
• DNS Private Resolver makes sure the Key Vault name resolves to its private IP.

Setting up this architecture took me some time. Here are the things worth knowing before creating the resources, using a point-to-site VPN as the main example.

Things to watch out for

1. Plan your subnets before creating anything.

You need two dedicated subnets:

• GatewaySubnet — /27 or larger, for the VPN Gateway.
• Resolver inbound endpoint subnet — /28 or larger, delegated to Microsoft.Network/dnsResolvers.

Neither can share its subnet with other resources. Plan both into your VNet address space early.

2. Choose the right VPN Gateway SKU.

Avoid Basic if you need OpenVPN or Microsoft Entra ID authentication. For new deployments, start with VpnGw1AZ.

Also decide between the two connection types:

• Point-to-site: individual machines connect to Azure.
• Site-to-site: an entire office network connects to Azure.

Both can use Azure VPN Gateway, but their DNS configuration differs.

3. Watch out for overlapping IP ranges.

The point-to-site VPN client address pool must not overlap with your Azure VNet or the networks your users connect from.

Otherwise, routing may fail even though the VPN shows “Connected”.

4. You probably only need the resolver’s inbound endpoint.

For accessing Azure private endpoints from your machine, an inbound endpoint is enough.

An outbound endpoint and forwarding ruleset are used when Azure needs to forward DNS queries to other DNS servers, such as on-premises DNS.

5. Link the private DNS zone to the correct VNet.

For Key Vault, the private DNS zone is:

privatelink.vaultcore.azure.net

Make sure it contains the correct A record and is linked to the VNet hosting your DNS Private Resolver.

The private endpoint wizard may have created a zone and link already. Check before creating duplicates.

6. Configure DNS for the VPN connection.

Creating the resolver is not enough. Your clients must actually send DNS queries to it.

• Point-to-site: configure the resolver’s inbound IP as a custom DNS server in your VNet settings. Download the VPN client profile again after the change.
• Site-to-site: configure conditional forwarding on your office DNS server for vault.azure.net and vaultcore.azure.net, pointing to the resolver’s inbound IP.

Remember the inbound endpoint IP. If you use dynamic allocation, it can change when the endpoint is reprovisioned.

7. Check routing and firewall rules.

With split tunneling, make sure clients have routes through the VPN to both the resolver’s inbound IP and the Key Vault private endpoint IP.

If an NSG or firewall is in the path, allow DNS traffic over UDP and TCP port 53 to the resolver.

8. Network access does not replace permissions.

Even with working VPN connectivity and DNS, Key Vault still requires the correct data-plane permissions.

A 403 Forbidden can mean missing permissions or a Key Vault firewall rejection. Check in the RBAC of the resource.

9. Remember the ongoing costs.

Both VPN Gateway and DNS Private Resolver have ongoing charges, even when nobody is connected.

If you’re testing the architecture in a development environment, delete unused resources afterwards.

Summary

The important thing to remember: VPN Gateway handles connectivity, DNS Private Resolver handles name resolution. Both must be configured correctly for private endpoint access to work.