Use pure-Go DNS resolver to fix Private Link/PSC connectivity on macOS

[DrFaust92]

Summary

• Set PreferGo: true on the net.Resolver used by the SDK's default HTTP transport dialer
• Fixes DNS resolution issues on macOS when using Private Link / Private Service Connect

Problem

On macOS, Go's default cgo DNS resolver can bypass split-horizon DNS configurations. When a Databricks workspace is configured with Private Link or Private Service Connect, the workspace URL should resolve to a private IP via a private DNS zone. However, the cgo resolver may resolve to the public IP instead, causing requests to be blocked by IP ACLs with a confusing error:

Error: cannot update permissions: Source IP address: x.x.x.x is blocked by 
Databricks IP ACL for workspace: xxxxx

The workaround today is setting GODEBUG=netdns=go globally, but users have no way to know this from the error message alone.

Solution

Set PreferGo: true on the net.Resolver in the SDK's default HTTP transport dialer. This:

• Ensures the pure-Go DNS resolver is used, which correctly respects system DNS settings including private DNS zones
• Is scoped to the SDK's HTTP client only — does not affect other libraries or providers in the same process
• Falls back to the cgo resolver automatically if the Go resolver fails (it's a preference, not a hard requirement)
• Matches what GODEBUG=netdns=go does, but without requiring a global environment variable

Test plan

• Verified the change compiles
• Test on macOS with a Private Service Connect workspace — workspace URL should resolve to private IP
• Test on Linux — no behavioral change expected (Go resolver is already the default on Linux)

🤖 Generated with Claude Code

[renaudhartert-db]

Thanks for the detailed write-up and for digging into this.

I have a question about the underlying problem. My naive understanding is that this is a macOS-specific issue where the cgo resolver doesn't honor split-horizon DNS configs (e.g., /etc/resolver/*). If that's the case, I'm wondering whether the right fix lives in the SDK or on the user's machine — since other Go HTTP clients in the same process (or other tools hitting the same endpoint) would presumably hit the same issue.

A few things I'm genuinely uncertain about:

• (i) Is the pure-Go resolver actually more correct here, or does it happen to work because it reads different config files? I want to make sure we're not trading one set of DNS edge cases for another.
• (ii) Is this specific to how macOS handles private DNS zones, or is there a broader class of setups where the cgo resolver misbehaves? If it's narrow, documenting GODEBUG=netdns=go as a workaround might be more appropriate than changing the default for all users.
• (iii) Do you have more context on the DNS setup that triggers this? I want to make sure I'm not misunderstanding the problem. If there's something specific about how the SDK sets up its transport that makes this worse than a vanilla http.DefaultTransport, that would change my thinking.

I'm not opposed to the change itself — it's low-risk given the fallback behavior — but I want to make sure we're solving the right problem at the right layer before setting a precedent.

[DrFaust92]

To answer your questions briefly:

(i) macOS DNS resolution in Go has a well-documented history of issues with VPNs and split-horizon DNS (golang/go#12524, hashicorp/terraform#3536, helm/helm#11807). While Go 1.20+ improved things significantly by adding direct libSystem bindings, there are still behavioral differences between the cgo path (getaddrinfo → mDNSResponder) and the Go-managed path (res_search via libSystem) — particularly around how VPN DNS zone changes are picked up. In our case, GODEBUG=netdns=go resolves the Private Link resolution failure. With PreferGo: true + cgo fallback, there's no downside — if the Go resolver fails, it falls back to the system resolver automatically.

(ii) This affects any macOS user with Private Link/PSC behind a corporate VPN — a very common enterprise setup. The error (Source IP address is blocked by IP ACL) gives no hint that DNS is the root cause, so users spend hours debugging network/firewall issues. GODEBUG=netdns=go isn't a realistic workaround when the error doesn't point to DNS at all.

(iii) Typical setup: workspace with IP ACL + Private Link/PSC, macOS + corporate VPN with split-tunnel DNS routing private zones to an internal nameserver. The SDK transport is vanilla net.Dialer — nothing unusual — but since it's the HTTP client for all Go-based Databricks tooling (including the Terraform provider, where most reports come from), fixing it here has the broadest impact.

This is actively disruptive to local development on macOS without the fix or the GODEBUG workaround.

[github-actions]

If integration tests don't run automatically, an authorized user can run them manually by following the instructions below:

Trigger:
go/deco-tests-run/sdk-go

Inputs:

• PR number: 1589
• Commit SHA: 48792c4de04e929cc3d8fc976ccfbaffc5d4f255

Checks will be approved automatically on success.