How can I use Azure Private DNS Resolver to provide VPN-based access to a private Azure Databricks workspace without changing DNS settings on user machines?

Hello **Usman Rasheed
**It seems you want all your on-premises users connected via VPN to automatically resolve your private Databricks workspace endpoint, without having to update DNS settings on each PC. Azure DNS Private Resolver is a strong solution for this scenario. Here’s a high-level overview and responses to your specific questions:

Can Azure Private DNS Resolver be used so that all on-premises users connected through VPN can automatically resolve the private Azure Databricks endpoint?

Yes, you can deploy a DNS Private Resolver in Azure, typically within a “hub” VNet. Set up an inbound endpoint and configure your on-premises DNS servers to forward queries for the Databricks private link domain (privatelink.azuredatabricks.net) to this endpoint.

When on-premises clients request .azuredatabricks.net, your central DNS forwards those queries to the Resolver’s inbound IP, which returns the private IP address assigned by the Databricks private endpoint.

Is it possible to achieve this without changing DNS settings on each client machine?

Absolutely. End users should keep using the corporate DNS server IPs provided through DHCP or group policy. Only your central on-prem DNS requires a conditional forwarder for the Databricks private-link zone pointing to the Azure Resolver inbound endpoint. There’s no need for hosts file changes or DNS adjustments on individual PCs.

What is the recommended Azure architecture for this setup?

You can deploy the Azure private DNS resolver in the Azure Hub VNET and set up an inbound IP for the resolver. If you are using a custom DNS server in the private DNS resolver VNET, you need to configure a simple forwarder pointing to the Azure DNS IP (168.63.129.16). If you are using Azure DNS, no modifications are needed. The same applies to the private endpoint VNET (Spoke VNET); if you use a custom DNS server, you should set up a forwarder, either for both or at the VNET level, as required.

All VNETs must be linked to the private DNS zone, as this is mandatory. Once everything is configured in Azure, you need to set up a conditional forwarder on your on-prem DNS server machine, pointing to the Azure DNS resolver inbound IP. When you access the Databricks URL, the first request will go to the private DNS resolver and then route to your Databricks environment.

Check the document for more understanding: https://github.com/msrini-MSFT/Troubleshooting-Private-Link-DNS-Scenarios?tab=readme-ov-file#scenario-2---if-your-source-machine-is-deployed-on-premises-other-cloud

Do I only need to configure forwarding on the central on-premises DNS server so that all users inherit the configuration automatically?

Yes, if you are using a site-to-site setup, all users connect to the same network with the same DNS server. On the DNS server machine, you can configure a conditional forwarder that points to the private DNS resolver's inbound IP.

On-prem DNS → Conditional forwarder for privatelink.azuredatabricks.net → Azure Resolver inbound IP(s). Clients just use your on-prem DNS as usual.

If Azure Private DNS Resolver is the correct solution, how should the inbound endpoint, outbound endpoint, and DNS forwarding rules be configured for private access to Azure Databricks?

• Once you configure the DNS resolver, it will assign an inbound IP. You can then set up a conditional forwarder on the on-premises DNS server. For example, configure the on-prem DNS conditional forwarder for *.privatelink.azuredatabricks.net to point to inbound IPs.
• Outbound Endpoint (this is optional unless Azure VMs need to resolve on-premises names): Set it up in the “outbound” subnet and link a DNS forwarding ruleset that directs on-premises domains or other suffixes to your on-prem DNS IPs.
• Link your Hub VNet outbound endpoint to the ruleset so that Azure-originated queries for on-premises names are directed outbound. Also, ensure the Private DNS zone for Databricks is attached to the Hub VNet so the Resolver can respond to those queries.

Check the below public documents for more understanding:
Create an Azure DNS Private Resolver using the Azure portal

Azure DNS Private Resolver endpoints and rulesets

Azure Private Endpoint private DNS zone values

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "upvote" where the information provided will help you, this can be beneficial to other members of the community

1. Azure DNS Private Resolver can be used so that all on-premises users connected through VPN can automatically resolve the private Azure Databricks endpoint, provided that:
   • On-premises clients use a central on-premises DNS server for name resolution.
   • That on-premises DNS server is configured with conditional forwarders that send Databricks-related DNS queries to the Azure DNS Private Resolver inbound endpoint. DNS Private Resolver is designed exactly to bridge on-premises DNS with Azure private DNS zones and private endpoints, eliminating the need for DNS forwarder VMs in Azure and enabling hybrid name resolution.
2. It is possible to achieve this without changing DNS settings on each client machine, as long as:
   • Client machines are already configured (via DHCP/Group Policy or similar) to use the central on-premises DNS servers.
   • All Databricks-related DNS logic (conditional forwarding to Azure, private zone records, etc.) is handled centrally on those DNS servers and in Azure. No per-client conditional forwarders, hosts file entries, or local DNS changes are required; clients simply query the on-prem DNS as usual.
3. Recommended Azure architecture for this setup (aligned with the documented hybrid pattern):
   • Hub-and-spoke in Azure:
     • A hub virtual network that contains:
       • Azure DNS Private Resolver with:
         • Inbound endpoint in a dedicated subnet (for on-prem → Azure queries).
         • Outbound endpoint in a dedicated subnet (for Azure → on-prem or other DNS targets, if needed).
       • Private DNS zones for the Databricks private endpoints (for example, the Databricks private FQDN zones recommended for the workspace’s private endpoints) linked to the hub VNet.
       • Optional Azure Firewall if central egress control is required.
     • Spoke VNets that host the Databricks workspace and its private endpoints, peered with the hub VNet.
   • On-premises side:
     • Site-to-site VPN or ExpressRoute to the hub VNet (as in the documented hybrid architectures).
     • One or more central on-premises DNS servers used by all clients.
     • Conditional forwarders on those DNS servers for the Databricks private endpoint zones pointing to the DNS Private Resolver inbound endpoint IP in the hub.
   This mirrors the documented pattern where on-prem DNS uses conditional forwarders to the DNS Private Resolver inbound endpoint, and the resolver in turn uses Azure private DNS and forwarding rules to resolve private endpoints.
4. Only forwarding needs to be configured on the central on-premises DNS servers so that all users inherit the configuration automatically, assuming they already use those DNS servers:
   • Configure conditional forwarders on the on-prem DNS servers for the Databricks private endpoint DNS zones (for example, the workspace’s private FQDN zones) to the DNS Private Resolver inbound endpoint IP address in the hub VNet.
   • On-prem clients continue to use the same DNS servers; they automatically benefit from the new forwarding rules without any local changes. This matches the pattern where “on-premises workloads use this approach to accurately resolve Azure private endpoint fully qualified domain names (FQDNs) to their corresponding private IP addresses” via conditional forwarders to the DNS Private Resolver inbound endpoint.
5. If Azure DNS Private Resolver is used, configuration should follow the documented hybrid design:
   • Inbound endpoint:
     • Deployed in a dedicated subnet in the hub VNet (for example, /28 as recommended for scaling).
     • Assigned an IP address (for example, 10.0.0.8 in the reference architecture) that on-prem DNS servers use as the target for conditional forwarders.
     • Purpose: receive DNS queries from on-prem DNS for Databricks private endpoint zones.
   • Outbound endpoint:
     • Deployed in a separate dedicated subnet in the same hub VNet (for example, 10.0.0.16/28 with an IP such as 10.0.0.19 in the reference architecture).
     • Used if Azure-side workloads need to resolve on-premises domains or other external DNS via conditional forwarding rules.
     • For a Databricks-access-only-from-on-prem scenario, outbound may be optional unless Azure workloads also need to resolve on-prem names.
   • DNS forwarding rule set:
     • Associated with the resolver’s virtual network.
     • Contains rules that specify domain names and target DNS servers for conditional forwarding.
     • For Databricks private access, typical rules include:
       • Forward on-premises domains (for example, onpremises.company.com) to on-prem DNS via the outbound endpoint, if Azure workloads need to reach on-prem apps.
       • If Databricks or other services require specific external DNS behavior, add rules accordingly.
     • For Databricks private endpoints themselves, resolution is usually handled directly via Azure private DNS zones linked to the hub VNet; the resolver will query Azure private DNS first and then Azure DNS if no private record is found.
   • Private DNS zones:
     • Create and link the Databricks-related private DNS zones to the hub VNet that hosts the resolver.
     • Private endpoint A records for the Databricks workspace are stored in these zones so that DNS Private Resolver can return the private IPs to on-prem clients.
   End-to-end flow for an on-prem user over VPN:
   1. User’s machine queries the Databricks workspace FQDN using its normal DNS settings (on-prem DNS server IPs).
   2. On-prem DNS sees a Databricks private endpoint zone match and uses the conditional forwarder to send the query to the DNS Private Resolver inbound endpoint in Azure.
   3. DNS Private Resolver checks Azure private DNS zones linked to its VNet; finds the Databricks private endpoint record and returns the private IP.
   4. On-prem DNS returns this private IP to the client, which then connects over the VPN to the Databricks private endpoint.
   This architecture centralizes DNS management on the on-prem DNS servers and Azure DNS Private Resolver/Azure private DNS, with no per-client DNS configuration changes required.

References:

• Azure DNS Private Resolver
• Azure Private Endpoint DNS integration Scenarios
• How to use your workspace with a custom DNS server