Serverless DNS failures after trial upgrade (AWS us-east-2)

[revian]

Our AWS Premium serverless workspace in us-east-2 cannot resolve several public domains. We added a payment method, and the account UI confirms that the trial upgrade is complete.

Three fresh serverless notebook runs on September 24, 2026, at approximately 15:01, 15:04 and 15:13 UTC produced the same results using Python's socket.getaddrinfo:

• app.bellesoftware.com.br, www.google.com, and example.com: gaierror: [Errno -3] Temporary failure in name resolution.
• pypi.org and www.databricks.com: resolve successfully.

An HTTPS request to the external API fails with requests.exceptions.ConnectionError before API authentication. That API is reachable from our local computer.

The account network-policy API reports default-policy as FULL_ACCESS with ENFORCED mode and no blocked destinations. However, this is a Premium workspace, and the documentation says default policies apply only to Enterprise workspaces, so we do not assume that response establishes the effective egress permissions.

Could a trial-related DNS or outbound restriction remain after the upgrade? How can we verify whether one is still applied and have it removed? If this is unrelated to trial restrictions, which serverless networking configuration or diagnostic should we check next?

This is blocking the initial load for a daily REST API ingestion job. We can provide workspace details and diagnostic run IDs privately to Databricks support.

[revian]

My account Id: e5beacb1-d0a7-44cd-8de6-8d6f89d5af81

[ivanvyd]

@revian thanks for the detailed diagnostics. If the account used express setup, Databricks notes that some trial restrictions can persist after upgrading. A remaining network restriction is worth checking, but isn't confirmed here.

If available, check system.access.outbound_network for DNS events matching your test timestamps. A matching DROP indicates an enforced denial; DRY_RUN_DENIAL doesn't. No matching events would be inconclusive, since coverage of trial restrictions on Premium isn't clearly documented.

[lmcorreahdb]

One additional diagnostic could help distinguish a workspace-level trial restriction from a standard serverless egress policy.

Since serverless network policies currently require Enterprise tier, and the default policy is only applied to Enterprise workspaces, the FULL_ACCESS response from the account API would not necessarily explain the effective behavior of this Premium workspace.

I would run the same DNS test while querying system.access.outbound_network for the exact workspace_id, timestamps, and failing destinations.

If there is a DROP event, that gives Databricks Support a concrete policy enforcement event to trace.

If there is no event, I would also test the same domains from a newly created post-upgrade workspace in the same region, if your account allows it. If the new workspace resolves them while the original Express Setup workspace does not, that would be a useful signal that the restriction is tied to the original trial workspace rather than the destination itself.

Given that Databricks documentation notes that some Express Setup trial limitations may remain after upgrading, I would include both workspace IDs and the failing run timestamps in the support case and ask them specifically to verify whether any internal trial-era serverless egress restriction is still attached to the original workspace.

I would also avoid treating the account default-policy response as proof of effective egress configuration for this Premium workspace.