Comment by ninkendo

3 years ago

It also doesn’t play well with split tunnel VPN’s on macOS that are configured for particular DNS suffixes. If you have a VPN that is only active for connections in a particular domain, git-lfs (and I think any go software, by default) will try to use your non-VPN connection for connections that should be on the VPN.

I don’t know why it is, exactly… but I think it’s related to Golang intentionally avoiding using the system libc and implementing its own low-level TCP/IP functions, leading to it not using the system configuration which tells it which interface to use for which connections.

Edit: now that I think about it, I think the issue is with DNS… macOS can be configured such that some subdomains (like on a VPN) are resolved with different DNS servers than others, which helps isolate things so that you only use your VPN’s DNS server for connections that actually need it. Go’s DNS resolution ignores this configuration system and just uses the same server for all DNS resolution, hence the issue.

5 comments

ninkendo

Reply
SomaticPirate  3 years ago

Go’s choice to default to its own TCP/IP implementation has bitten me personally to the level of requiring a machine restart.

The Go IPv6 DNS resolution on MacOS can cause all DNS requests on the system to begin to fail until a restart.

https://github.com/golang/go/issues/52839

  • alecthomas  3 years ago

    Not to understate the impact of the bug, but this is not the default for Go. It is used if CGo is disabled, as the issue you linked to describes.

  • EdiX  3 years ago

    The OS network stack is crashing and this is Go's fault? Is Go holding the network stack wrong?