3 ms·

It doesn't require cgo, but it defaults to it on linux. To quote from the official docs: https://golang.org/pkg/net/#hdr-Name_Resolution https://golang.org/pk

It doesn't require cgo, but it defaults to it on linux. To quote from the official docs: https://golang.org/pkg/net/#hdr-Name_Resolution https://golang.org/pkg/net/#hdr-Name_Resolution > When cgo is available, the cgo-based resolver is used instead under a variety of conditions: .... when /etc/resolv.conf or /etc/nsswitch.conf specify the use of features that the Go resolver does not implement, and when the name being looked up ends in .local or is an mDNS name. Almost any linux machine's `/etc/nsswitch.conf` will contain features that the go resolver doesn't implement. Because of that, almost any dns resolution will default to cgo. In addition, selecting between netgo and cgo is a runtime feature by default (see GODEBUG=netdns=go|c), so it still has to build it in regardless unless it's explicitly disabled. You can also determine this by using `ldd` on a go binary. > Only programs that expliticly call C functions (i.e. those that use ‘import “C”’) do. That is exactly what go uses in programs that use networking. Here's the 'import "C"' in question: https://github.com/golang/go/blob/fe8a0d12b14108cbe2408b417afcaab722b0727c/src/net/cgo_linux.go#L9-L12 https://github.com/golang/go/blob/fe8a0d12b14108cbe2408b417a...

otterley 8y ago
Thanks for the clarification!
TheDong 8y ago
(note for anyone coming by in the future: that link is not the best one, https://github.com/golang/go/blob/fe8a0d12b14108cbe2408b417afcaab722b0727c/src/net/cgo_unix.go#L5-L18 https://github.com/golang/go/blob/fe8a0d12b14108cbe2408b417a... is where most of the cgo code for linux is)
e12e 8y ago
> Almost any linux machine's `/etc/nsswitch.conf` will contain features that the go resolver doesn't implement. Do you know of a short list of top features missing? I would kinda hope that modern and generally useful features would be in netgo. And old rotted code, security risks and anachronisms would be abandoned. But from your tone, I gather that this is more than a "people only use 10%, but never the same 10%" type of thing?
- TheDong 8y ago
  Here's the code that determines if it needs to fall back to cgo: https://github.com/golang/go/blob/161874da2ab6d5372043a1f3938a81a19d1165ad/src/net/conf.go#L122-L280 https://github.com/golang/go/blob/161874da2ab6d5372043a1f393... Notably, it can only handle the following sources: files, dns, myhostname, mdns* (but only a subset of those if you read the gory details). It doesn't handle the fairly uncommon "mymachines" or "resolve" (sometimes used in the systemd world nowadays) I probably spoke too pessimistically there. Many machines won't have an nsswitch.conf that requires using cgo for common domains. After re-reading the code, it does handle more than I thought (mainly mdns). > I would kinda hope that modern and generally useful features would be in netgo. And old rotted code, security risks and anachronisms would be abandoned The fundamental problem here is not that. The nss system libc uses for network resolution is a pluggable system, and it chose dynamically linked c modules as its plugins. It's not that they're old rotted insecure bits of code, it's that the interface is inherently a c-centric one, and go early on decided it wished to do syscalls directly instead of call them through libc (as literally every other programming language does). Finally, that means go can't ever reach full parity as long as it wishes to avoid c, since anyone can simply write a new nss plugin in c and list it in resolv.conf, and go has no way of having that same arbitrary behaviour in go.
  - e12e 8y ago
    Thank you for taking the time to reply. > that means go can't ever reach full parity as long as it wishes to avoid c Well, go has for better or worse decided on a "we'll bring our own batteries" approach - and that does imply a burden of re-inventing a lot of wheels. On the other hand, those wheels are all likely to be painted in just the right shade of gopher brown. At a glance, nis/yp appear to be missing. Not sure if nis doesn't count as outdated though.

otterley 8y ago

Thanks for the clarification!

TheDong 8y ago

(note for anyone coming by in the future: that link is not the best one, https://github.com/golang/go/blob/fe8a0d12b14108cbe2408b417afcaab722b0727c/src/net/cgo_unix.go#L5-L18 https://github.com/golang/go/blob/fe8a0d12b14108cbe2408b417a... is where most of the cgo code for linux is)

e12e 8y ago

> Almost any linux machine's `/etc/nsswitch.conf` will contain features that the go resolver doesn't implement. Do you know of a short list of top features missing? I would kinda hope that modern and generally useful features would be in netgo. And old rotted code, security risks and anachronisms would be abandoned. But from your tone, I gather that this is more than a "people only use 10%, but never the same 10%" type of thing?

TheDong 8y ago
Here's the code that determines if it needs to fall back to cgo: https://github.com/golang/go/blob/161874da2ab6d5372043a1f3938a81a19d1165ad/src/net/conf.go#L122-L280 https://github.com/golang/go/blob/161874da2ab6d5372043a1f393... Notably, it can only handle the following sources: files, dns, myhostname, mdns* (but only a subset of those if you read the gory details). It doesn't handle the fairly uncommon "mymachines" or "resolve" (sometimes used in the systemd world nowadays) I probably spoke too pessimistically there. Many machines won't have an nsswitch.conf that requires using cgo for common domains. After re-reading the code, it does handle more than I thought (mainly mdns). > I would kinda hope that modern and generally useful features would be in netgo. And old rotted code, security risks and anachronisms would be abandoned The fundamental problem here is not that. The nss system libc uses for network resolution is a pluggable system, and it chose dynamically linked c modules as its plugins. It's not that they're old rotted insecure bits of code, it's that the interface is inherently a c-centric one, and go early on decided it wished to do syscalls directly instead of call them through libc (as literally every other programming language does). Finally, that means go can't ever reach full parity as long as it wishes to avoid c, since anyone can simply write a new nss plugin in c and list it in resolv.conf, and go has no way of having that same arbitrary behaviour in go.
- e12e 8y ago
  Thank you for taking the time to reply. > that means go can't ever reach full parity as long as it wishes to avoid c Well, go has for better or worse decided on a "we'll bring our own batteries" approach - and that does imply a burden of re-inventing a lot of wheels. On the other hand, those wheels are all likely to be painted in just the right shade of gopher brown. At a glance, nis/yp appear to be missing. Not sure if nis doesn't count as outdated though.