net: race condition in dnsclient_unix.go resolverConfig init

[christievans]

Please answer these questions before submitting your issue. Thanks!

1. What version of Go are you using (go version)?
   go version go1.6 linux/amd64
2. What operating system and processor architecture are you using (go env)?
   GOARCH="arm"
   GOHOSTARCH="amd64"
   GOHOSTOS="linux"
   GOOS="linux"
   GO15VENDOREXPERIMENT="1"
   CC="gcc"
   GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
   CXX="g++"
   CGO_ENABLED="1"
3. What did you do?

We were seeing issues where systems in the field would get stuck reporting:

dial tcp: lookup mywebsite.com on [::1]:53: read udp [::1]:50878->[::1]:53: read: connection refused

even though /etc/resolv.conf was populated with a legitimate nameserver. Restarting the application fixed the issue.

We believe this happens when net/dnsclient_unix.go resolverConfig.init() happens to run at the same time as /etc/resolv.conf being updated from empty to populated. There's a chance for:

1. Go reads empty /etc/resolv.conf, stores in conf.dnsConfig
2. /etc/resolv.conf gets updated
3. Go stat's /etc/resolv.conf, gets the new modTime and saves to conf.modTime
4. Go thinks there are no nameservers, and based on modTime seemingly not changing, never refreshes conf.dnsConfig

[ianlancetaylor]

CC @mdempsky

[mdempsky]

I think this is the same issue as #14072, which was fixed in golang.org/cl/18860. I'd be interested to know if you're able to reproduce the problem with Go at tip.

[mdempsky]

Alternatively, I think you should be able to backport that CL to 1.6 for testing.

[bradfitz]

@christievans, can you confirm whether this is fixed for you at tip?

[christievans]

I pulled in the CL and that fixed it - thanks for the quick response!