Comment by Beltalowda
3 years ago
I guess that kind of proves the point that there is no "stable", well, anything on Linux. Something like /etc/resolv.conf is part of the user-visible API on Linux; if you change that, you're going to break applications.
/etc/sysctl.conf is a good example; on some systems it just works, on some systems you need to enable a systemd service thingy for it, but on some systems the systemd thingy doesn't read /etc/sysctl.conf and only /etc/sysctl.d.
So a simple "if you're running Linux, edit /etc/sysctl.conf to make these changes persist" has now become a much more complicated story. Writing a script to work on all Linux distros is much harder than it needs to be.
> Something like /etc/resolv.conf is part of the user-visible API on Linux; if you change that, you're going to break applications.
Apps were not supposed to open /etc/resolv.conf by themselves. If they did, they are broken. Just because the file is available, transparently, doesn't mean it is not a part of the internal implementation.
Even golang runtime checks nsswitch for known, good configuration before using resolv.conf instead of thunking to glibc.
The point was that if you're statically linking something that paths such as /etc/resolv.conf become "hard-coded", so that seems like an unimportant detail; something needs to check it, whether that's an application or an application through a library call: it's the same thing. /etc/nsswitch.conf is just kicking the can down the road from /etc/resolv.conf to /etc/nsswitch.conf.
What would exactly be that "something"?
Statically linking glibc was always strongly discouraged. Even if you did it, nss and iconv are always dynamically loaded, and they need symbols from glibc itself, so your statically-glibc-linked binary would need to load dynamic libc anyway!
No, something doesn't need to check it, today it exists only to serve broken applications (and systems broken by their admins). Its semantic doesn't allow to express the needs of resolvers today (like per-interface or per-zone resolving or other mechanisms, like mDNS).
How the resolver is configured is its internal issue; apps should just use getnameinfo().