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.