Home / Databricks on Azure

Databricks on AzureRunbookAdvanced

Sev1: Azure Databricks workspace unreachable for all users after a Private Link or DNS change

The workspace URL times out or shows a blank page for everyone, while jobs may still run. Check name resolution for the workspace and browser-authentication endpoints, fix private DNS zone links and records, and restore front-end connectivity without opening public access permanently.

Deepak Bhardwaj4 min read

Applies toAzure Databricks with front-end (user-to-workspace) Private Link, privatelink.azuredatabricks.net private DNS zone, browser_authentication endpoint, hub-spoke networks

Symptoms

  • https://adb-<id>.<n>.azuredatabricks.net times out or returns a connection error for users on the corporate network or VPN.
  • Login loops or a blank page after Entra ID sign-in (browser authentication endpoint unreachable).
  • Scheduled jobs may keep running (back-end connectivity is separate), but nobody can open the UI, and REST/CLI calls from on-prem tools fail.
  • Started after a change to private DNS zones, VNet links, DNS forwarders, the private endpoint, or publicNetworkAccess.

Step 1: what does the workspace URL resolve to? (2 minutes)

From an affected client:

Resolve-DnsName adb-1234567890123456.7.azuredatabricks.net
Test-NetConnection adb-1234567890123456.7.azuredatabricks.net -Port 443

nslookup adb-1234567890123456.7.azuredatabricks.net
curl -sv https://adb-1234567890123456.7.azuredatabricks.net/login.html -o /dev/null 2>&1 | grep -E "Connected|HTTP/"
Result Meaning
Resolves to a private IP of your front-end private endpoint, port 443 fails Routing / NSG / firewall between client and endpoint
Resolves to a public IP and public access is disabled Private DNS not used by this client: zone link, forwarder or record missing
Does not resolve DNS forwarding chain broken
Resolves and connects, but login loops Browser authentication private endpoint / record missing

Step 2: check the private endpoint and DNS records

az network private-endpoint list -g rg-dbx-network \
  --query "[].{name:name, state:privateLinkServiceConnections[0].privateLinkServiceConnectionState.status, group:privateLinkServiceConnections[0].groupIds[0]}" -o table

az network private-dns record-set a list -g rg-dns -z privatelink.azuredatabricks.net \
  --query "[].{name:name, ip:aRecords[0].ipv4Address}" -o table

az network private-dns link vnet list -g rg-dns -z privatelink.azuredatabricks.net \
  --query "[].{vnet:virtualNetwork.id, state:virtualNetworkLinkState}" -o table

You need:

  • An A record for the workspace (adb-<id>.<n>) pointing at the front-end private endpoint IP (databricks_ui_api group).
  • An A record for the region's browser authentication endpoint (created by a browser_authentication private endpoint, usually one per region in a dedicated "web auth" workspace).
  • A VNet link from the zone to the VNet where your DNS resolvers or forwarders live (hub), not only to the workspace VNet.

Warning

If someone deleted and recreated the private endpoint, it may have a new IP, and the old A record now points nowhere. Compare the record with the endpoint's current NIC IP.

az network private-endpoint show -g rg-dbx-network -n pe-dbx-ui \
  --query "customDnsConfigs[].{fqdn:fqdn, ip:ipAddresses[0]}" -o table

Step 3: fix DNS

Recreate or correct records:

az network private-dns record-set a add-record -g rg-dns -z privatelink.azuredatabricks.net \
  -n adb-1234567890123456.7 -a 10.20.1.5

Better: attach a private DNS zone group to the endpoint so Azure maintains the record:

az network private-endpoint dns-zone-group create -g rg-dbx-network --endpoint-name pe-dbx-ui \
  -n default --private-dns-zone $(az network private-dns zone show -g rg-dns -n privatelink.azuredatabricks.net --query id -o tsv) \
  --zone-name databricks

Restore the hub VNet link if it was removed:

az network private-dns link vnet create -g rg-dns -z privatelink.azuredatabricks.net \
  -n link-hub --virtual-network $(az network vnet show -g rg-hub -n vnet-hub --query id -o tsv) --registration-enabled false

On-prem DNS: confirm the conditional forwarder for azuredatabricks.net (or privatelink.azuredatabricks.net) still points to your Azure DNS Private Resolver inbound endpoint or DNS forwarder VMs.

Flush client caches after fixing: ipconfig /flushdns.

Step 4: fix the network path

If DNS is right but port 443 fails:

  • NSG on the private endpoint subnet (if network policies for private endpoints are enabled) must allow 443 from client ranges.
  • Azure Firewall / NVA rules for traffic from on-prem or VPN ranges to the endpoint subnet.
  • UDRs on the gateway subnet sending return traffic correctly.
az network watcher test-ip-flow --direction Inbound --protocol TCP \
  --local 10.20.1.5:443 --remote 192.168.50.20:50000 --vm <a-vm-in-the-same-subnet-for-testing>

Step 5: emergency access (only if needed)

If the business needs the UI before DNS is fixed and policy allows it, a temporary option is to allow public access restricted by IP access lists:

az databricks workspace update -g rg-dbx -n dbx-prod --public-network-access Enabled

Caution

Only do this with IP access lists configured first, and revert the same day. Some organisations forbid it outright; check your security policy before using it.

Step 6: confirm

  • Workspace URL resolves to the private IP from on-prem, VPN and Azure clients.
  • Login works end to end (browser auth).
  • CLI from an on-prem host: databricks current-user me.
  • Public network access back to Disabled if you changed it.

Prevent it next time

  • Private DNS zone groups on every Databricks private endpoint, so records follow the endpoint.
  • Resource locks on the private DNS zone, its VNet links and the endpoints.
  • A synthetic check from on-prem that resolves and opens the workspace URL every five minutes.
  • Change process for hub DNS that lists every privatelink zone and its consumers.

Related fixes