net: NATs client can't connect to server when client built with go1.7: "dial tcp: no suitable address found" #16739
Comments
What does running with environment variable I suspect your Go 1.6 vs Go 1.7 differ in how they were built (cgo/netgo/etc), because I don't think anything changed in this area during Go 1.7. /cc @mdempsky |
Possibly; although the only change I made was to use a different image (1.7 vs 1.6.2).
Will have a go now. If this doesn't help, I can try and provide a minimal reproduction tomorrow. |
With go1.7rc6:
|
Can you compare that with Go 1.6? For your Go 1.7 output, I see:
I think the relevant change in Go 1.7 was 72c1180 (net: don't do DNS for onion and local addresses) for #13705. When @mikioh mentioned RFC 6762, which says:
I missed this part:
And currently we're just always skipping DNS for *.local addresses: // avoidDNS reports whether this is a hostname for which we should not
// use DNS. Currently this includes only .onion and .local names,
// per RFC 7686 and RFC 6762, respectively. See golang.org/issue/13705.
func avoidDNS(name string) bool {
if name == "" {
return true
}
if name[len(name)-1] == '.' {
name = name[:len(name)-1]
}
return stringsHasSuffixFold(name, ".onion") || stringsHasSuffixFold(name, ".local")
} We should probably relax the *.local case, at least for the I doubt it's relevant, but what is your /etc/resolv.conf and /etc/nsswitch.conf? /cc @mikioh @mdempsky @ianlancetaylor for any opinions and whether this is Go 1.7.1 worthy. |
I am definitely for relaxing the *.local case. We use DNS for resolving .local domains and this is a blocker for us to go to Go 1.7. We actually have a local DNS server setup specifically for this case, which is local to the machine, and not propagated to upstream DNS servers. |
Thanks for looking into this! Relaxing the .local sounds like a plan, as things like kubedns and weavedns depend heavily on it. |
@bradfitz I put together a quick CL to relax the .local case: https://go-review.googlesource.com/#/c/27250/ |
Sorry just realised there were some more outstanding questions:
These jobs are running inside an Alpine container:
|
CL https://golang.org/cl/27250 mentions this issue. |
|
Alas, but as mentioned in https://tools.ietf.org/html/draft-adpkja-dnsop-special-names-problem, it's better to stay away from the disturbance of TLD usage. |
.local addresses are used by things like Kubernetes and Weave DNS; Go should not avoid resolving them. This is a partial revert of https://golang.org/cl/21328 which was too strict of an interpretation of RFC 6762. Fixes #16739 Change-Id: I349415b4eab5d61240dd18217bd95dc7d2105cd5 Reviewed-on: https://go-review.googlesource.com/27250 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/28632
cGo DNS resolution of Working around this by configuring environment variable |
@mcandre, if you have a bug report, please file a new bug. We don't track closed issues. I'm not sure what you're saying, though. I don't know what you mean by "broken", or what a Kubernetes scenario means. |
I am interested in the postgres_exporter releases built with any Go > 1.7.0 since that should fix the issue golang/go#16739 in Go.
Includes fix for this issue: golang/go#16739
Please answer these questions before submitting your issue. Thanks!
go version
)?go1.7rc6 from docker hub:
go env
)?Minikube - x86 VirtualBox VM on a Mac
Compiled Weave Scope with go1.7 (see weaveworks/scope#1797), ran it on a minikube instance and it couldn't connect to a NATs instance:
The "nats: no servers available for connection" comes form the NATS client, which hides the original error. the "dial tcp: no suitable address found" is me adding some logging to the client to show the error.
Kubectl exec'ing into a pod on the machine shows NATs is indeed accessible:
I expect it to connect and work, as it does with go1.6
The text was updated successfully, but these errors were encountered: