Disable CGO for improved compatibility and performance

[vyasgun]

Fixes: #500

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: vyasgun
Once this PR has been reviewed and has the lgtm label, please assign baude for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[cfergeau]

Are they any tradeoffs to doing this? changes in behaviour in DNS resolution/…?

[vyasgun]

@cfergeau The DNS tests are passing. Are there other tests that I can try for this?

[fessyfoo]

Please reconsider disabling cgo.

Doing so will likely break DNS for macOS (Darwin) users, and possibly others.

• no multicast dns support (mdns/avahi)
• no support for VPN or other local DNS configured on darwin.
• ...

[cfergeau]

Please reconsider disabling cgo.

Doing so will likely break DNS for macOS (Darwin) users, and possibly others.

* no multicast dns support  (mdns/avahi)

* no support for VPN or other local DNS configured on darwin.

* ...

Thanks! This is exactly the kind of feedback I was looking for in #550 (comment) so that we can make an informed decision :) Do you have an example of a VPN config which would be broken by this?

It’s for linux builds that this would be most useful, so one option is to only disable it there.

[fessyfoo]

I'm gonna roll back my concerns.

macos

we had a lot of problems with macos developer endpoints which left me with scars. :D

We saw

• issues with split horizon dns on vpns (no resolving internal domains)
• some teams wanting t use the /etc/resolver feature on macos.

but looks like those are old scars and golang solved this in 1.20 for macos.

Starting in Go 1.201, DNS lookups when running on macOS will be done via the system instead of via Go’s built-in resolver. That’s even when cgo is not available
-- https://danp.net/posts/macos-dns-change-in-go-1-20

IIUC I think that alleviates any of my dns cgo concerns for darwin/macos

linux

I suspect that on linux it's even more safe. I expect situations where people are using nsswitch to configure something different from pure go implementations are rare.

but they could happen such as when using LDAP or NIS.

mDNS, and LLMNR on linux would work when using systemd-resolved and the stub-resolver. and any host system needing those things is likely a user endpoint which probably is running systemd-resolved.

so some subset of folks may need a way to get a cgo build. again i expect that to be fairly small.

[vyasgun]

thanks @fessyfoo! I've updated pkg/services/dns/dns.go to use the system resolver. I tried the following setup:

resolver := net.Resolver{
    PreferGo: false,
}

I verified split-horizon DNS behaviour using a local test environment:

• Configured dnsmasq with test DNS mappings (e.g., test.testlocal to 192.168.99.99)
• Created /etc/resolver/testlocal pointing to dnsmasq (127.0.0.1:53)
• Started gvproxy and connected a vfkit VM
• Queried the test domain from the VM using gvproxy's DNS server (192.168.127.1)

With PreferGo: true:

$ nslookup test.testlocal 192.168.127.1
** server can't find test.testlocal: NXDOMAIN

With PreferGo: false:

$ nslookup test.testlocal 192.168.127.1
Name:   test.testlocal
Address: 192.168.99.99

Just pushed the change to not prefer Go's built-in DNS resolver.