Databricks App in Azure Databricks with private link cluster (no Public IP)

Behwar
New Contributor III

‎01-17-2025 04:01 AM

Hello,
I've deployed Azure Databricks with a standard Private Link setup (no public IP). Everything works as expected—I can log in via the private/internal network, create clusters, and manage workloads without any issues.

When I create a Databricks App, it generates a URL like: <name>.azure.databricksapps.com

Since I didn’t initially have a Private DNS Zone for azure.databricksapps.com, my system resolved this address to a public IP. To fix this, I:

  • Created a Private DNS Zone for azure.databricksapps.com.
  • Added an A record pointing <name>.azure.databricksapps.com to my Databricks workspace private IP endpoint (same as used in privatelink.azuredatabricks.net for this workspace).

Behavior Before Adding the Private DNS Zone:
nslookup <app-name>.azure.databricksapps.com → Resolved to a public IP.
curl or accessing via a browser resulted in:
{"X-Databricks-Reason-Phrase":"Public access is not allowed for workspace: xyz"}

Behavior After Adding the Private DNS Zone:
nslookup <app-name>.azure.databricksapps.com → Now resolves to the private IP (as expected).
However, curl and browser requests still go through the public IP and return the same error:
{"X-Databricks-Reason-Phrase":"Public access is not allowed for workspace: xyz"}

Is additional configuration needed to ensure Databricks Apps work over Private Link?
Does this feature require a Public IP, or should it work fully within a private network?

Alberto_Umana
Databricks Employee
Databricks Employee

‎01-17-2025 04:40 AM

Hello @Behwar,

Did you make sure that your internal DNS is configured to map the web application workspace URL to your front-end VPC endpoint. This involves creating an A-record in your internal DNS that maps the workspace URL directly to the front-end (workspace) VPC endpoint private IP

0 Kudos

Behwar
New Contributor III
In response to Alberto_Umana

‎01-17-2025 05:12 AM

I'm using Azure, so instead of a VPC endpoint, I'm working with Azure Private Link. Here's what I checked and did:

  • Verified my Databricks workspace private endpoint under privatelink.azuredatabricks.net.
  • Created a Private DNS Zone for azure.databricksapps.com and mapped <app-name> to the same private IP as my Databricks workspace.
  • Linked my VNet to the Private DNS Zone so all internal resources resolve it correctly.
  • Confirmed that nslookup now returns the private IP, but browser and curl still attempt to route via the public IP.
0 Kudos

sparkplug
Contributor

‎02-20-2025 12:38 AM

I am also facing the same issue. Is the recommendation to create one A-record for each app, which sounds a bit cumbersome.

 

0 Kudos

MariuszK
Valued Contributor III

‎02-21-2025 11:10 AM

Do you have a private endpoint for databricks_ui_api ? You need to establish a private endpoint for users to access web app.

0 Kudos

rugger-bricks
Databricks Employee
Databricks Employee

‎04-14-2025 10:24 AM

Behwar : you should have to create a specific private DNS zone for azure.databricksapps.com - if you do a nslookup on your apps url - you will see that it points to your workspace. In Azure using Azure (recursive) DNS you can see an important behavior that will give you a clue on how to handle apps with a workspace that has no public access that uses a private endpoint for access. 
If I do a nslookup -debug on my apps URL, the url points to a canonical (CNAME) of the databricks workspace URL, that URL points to a canonical (CNAME) to the privatelink URL which depending on if I have a private DNS zone or forwarding rule should either stop there and resolve to a private IP address or if not continue on to point to the regional control plane endpoint. 

Example : I have my app "yoworlld" and if I do a nslookup -debug without a private DNS zone you can see this behavior : 

 

% nslookup -debug yoworld-7338663619064447.7.azure.databricksapps.com 
Server:		10.248.117.1
Address:	10.248.117.1#53

------------
    QUESTIONS:
	yoworld-7338663619064447.7.azure.databricksapps.com, type = A, class = IN
    ANSWERS:
    ->  yoworld-7338663619064447.7.azure.databricksapps.com
	canonical name = adb-7338663619064447.7.azuredatabricks.net.
	ttl = 300
    ->  adb-7338663619064447.7.azuredatabricks.net
	canonical name = adb-7338663619064447.7.privatelink.azuredatabricks.net.
	ttl = 300
    ->  adb-7338663619064447.7.privatelink.azuredatabricks.net
	canonical name = westus.azuredatabricks.net.
	ttl = 300
    ->  westus.azuredatabricks.net
	internet address = 13.91.180.32
	ttl = 41

 

Same URL with private endpoints and a private DNS zone for privatelink.azuredatabricks.net linked to my vnet : 

 

> yoworld-7338663619064447.7.azure.databricksapps.com
Server:168.63.129.16
Address:168.63.129.16#53

Non-authoritative answer:
yoworld-7338663619064447.7.azure.databricksapps.com canonical name = adb-7338663619064447.7.azuredatabricks.net.
adb-7338663619064447.7.azuredatabricks.net canonical name = adb-7338663619064447.7.privatelink.azuredatabricks.net.
Name:adb-7338663619064447.7.privatelink.azuredatabricks.net
Address: 100.64.254.16

 

You can see that it found the private IP for the workspace private endpoint on its own. 

The challenge is if you are not using Azure DNS, or a properly configured forwarder, the hand off to the workspace URL is lost. For custom DNS you may need to add a CNAME that points to the workspace URL or an A record that points to the private endpoint IP address. 

0 Kudos