Private Route53 hosted zone for cloud.databricks.com

[margarita_shir]

We have Tailscale deployed on the same VPC as our Databricks workspaces. To enable PrivateLink for some workspaces, we created a private Route53 hosted zone for cloud.databricks.com with CNAME records pointing workspace hostnames to the PrivateLink endpoint.

The problem is that this private zone shadows all of *.cloud.databricks.com within the VPC, including:

• accounts.cloud.databricks.com — needed for public authentication
• ui-assets.cloud.databricks.com — CDN for UI static assets

For accounts.cloud.databricks.com we worked around this by adding an explicit A alias record in the private zone pointing to the public ELB. However, Databricks recently rotated that ELB hostname, breaking our hardcoded record.

For ui-assets.cloud.databricks.com — we only discovered today that this subdomain is also under cloud.databricks.com and was returning NXDOMAIN from the private zone, causing a blank page on all workspaces for Tailscale users.

Question: What is the recommended approach for maintaining a private hosted zone for cloud.databricks.com while keeping public subdomains like accounts and ui-assets resolvable? Is there a supported way to handle this without hardcoding ELB hostnames that can rotate?

Thank you,

[suranga]

The safer approach is not to shadow cloud.databricks.com with one private hosted zone. Databricks recommends the privatelink.cloud.databricks.com DNS pattern with conditional forwarding, which avoids hardcoding rotating ELB hostnames and keeps public services like accounts and ui-assets resolvable through normal public DNS.

[stbjelcevic]

Your current setup is a known anti-pattern. By creating a PHZ for cloud.databricks.com, you're shadowing every subdomain under that zone, including accounts, ui-assets, and any future public subdomains Databricks adds.

How it works

Databricks workspace URLs resolve through a CNAME chain:

<workspace>.cloud.databricks.com → <region>.privatelink.cloud.databricks.com

So the PHZ only needs to cover privatelink.cloud.databricks.com with regional A records pointing to your VPC endpoint private IPs. This leaves all public subdomains (accounts, ui-assets, etc.) resolving normally through public DNS.

Recommended Steps

1. Create a new PHZ for privatelink.cloud.databricks.com associated with your VPC
2. Add A records for your region(s), e.g. us-east-1.privatelink.cloud.databricks.com → VPC endpoint private IPs
3. Delete the old cloud.databricks.com PHZ
4. Verify accounts.cloud.databricks.com and ui-assets.cloud.databricks.com resolve publicly again

This eliminates all hardcoded ELB hostnames and is resilient to Databricks infrastructure rotations.

References
- https://docs.databricks.com/aws/en/security/network/classic/privatelink-dns
- https://community.databricks.com/t5/community-articles/configuring-dns-resolution-for-private-databr...