Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: missing /etc/resolv.conf on Linux means query localhost #10566

Closed
mdempsky opened this issue Apr 24, 2015 · 8 comments
Closed

net: missing /etc/resolv.conf on Linux means query localhost #10566

mdempsky opened this issue Apr 24, 2015 · 8 comments

Comments

@mdempsky
Copy link
Member

http://man7.org/linux/man-pages/man5/resolv.conf.5.html

   If this file does not exist, only the name server on the local
   machine will be queried; the domain name is determined from the
   hostname and the domain search path is constructed from the domain
   name.

See also Alex Skinner's comments at https://go-review.googlesource.com/#/c/8945/

@mdempsky
Copy link
Member Author

FreeBSD and NetBSD also document:

 On a normally configured system this file should not be necessary.  The
 only name server to be queried will be on the local machine, the domain
 name is determined from the host name, and the domain search path is con-
 structed from the domain name.

@axaxs
Copy link

axaxs commented Apr 24, 2015

Thank you. Further testing reveals this is the behavior also if resolv.conf exists and no nameservers are listed.

@mdempsky
Copy link
Member Author

Yeah, that seems to be the behavior I see looking at glibc, FreeBSD, NetBSD, and illumos's res_init functions: if /etc/resolv.conf is either missing or there are no "nameserver" lines, then localhost is used by default.

If I'm reading FreeBSD and NetBSD's correctly, it looks like they explicitly register both 127.0.0.1 and ::1 as default nameservers.

glibc and illumos only use 127.0.0.1 as the default name server.

OpenBSD also defaults to 127.0.0.1 if there's no "nameserver" line, but /etc/resolv.conf still has to exist or else it only uses /etc/hosts.

@axaxs
Copy link

axaxs commented Apr 24, 2015

Do you think it's acceptable to just use 127.0.0.1 and ::1 regardless of flavor? I don't see much harm in it. This is what my previous patch did. Secondly, should we differentiate openbsd in case that resolve.conf doesn't exist if we fix in dns_config? If we don't, regular builds will behave because Brad's change detects this. However people who build with netgo in openbsd would get the Linux behavior. If nobody else is working on it already, I can shoot a fix over tomorrow pending thoughts on the above.

@axaxs
Copy link

axaxs commented Apr 25, 2015

I have a fix for this written, just need to fix a couple tests and will submit. It's a rather large change because as I dug deeper there was more wrong/inconsistent. To name a few things, three global dns related structs named 'cfg', 'conf', and 'confVal' which was fun keeping track of, having resolv.conf rechecks only in netgo, and double parsing resolv.conf. I've removed conf and cfg, removed redundancies, and added rechecks for nsswitch and resolv.conf to the conf.go file. Not sure if more bug reports need to be opened individually, but I'd rather fix it in one go than peacemeal.

@bradfitz
Copy link
Contributor

Mail the change out once you have new tests (which fail now but should pass).

I may not be able to look at it until Tuesday morning.

@axaxs
Copy link

axaxs commented Apr 26, 2015

Thanks. I've submitted https://go-review.googlesource.com/#/c/9380/
It's my first in a while, and since move to git, so hopefully it's not too nightmarish.

Please review and if someone could kick off trybots on it that would be great.

@gopherbot
Copy link

CL https://golang.org/cl/9380 mentions this issue.

@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants