In case of Linux with glibc, check /etc/nsswitch.conf. The line in there starting with "hosts:" has the configured order of host name resolution methods, where "files" means /etc/hosts, and "dns" means /etc/resolv.conf. Other entries, like "mdns" or "mymachines" are additional optional modules and you should consult their respective documentation, and you can always uninstall them if you don’t want them.
Full documentation: https://www.gnu.org/software/libc/manual/html_mono/libc.html...
Re:Some ways DNS can break
by kiallmacinnes on Monday January 17, 2022 @04:58AM
(#29964979)
> This article ignores the most common problem I have with DNS these days which can roughly be construed as: What is actually handling resolution on my system?
This does my nut in too - even just narrowing the Q down to modern Linux Desktops with e.g. chrome/firefox, and I have absolutely no idea what the query path is. So many components have been added to the path over the last few years :(
Re:Some ways DNS can break
by octoberfranklin on Monday January 17, 2022 @05:03AM
(#29965004)
> Who is overwriting /etc/resolv.conf?
echo 'nameserver 127.0.0.1' > /etc/resolv.conf
chattr +i /etc/resolv.conf
Re:Some ways DNS can break
by klapatsibalo on Monday January 17, 2022 @05:24AM
(#29965131)
> A file with the 'i' attribute cannot be modified: it
cannot be deleted or renamed, no link can be created to
this file, most of the file's metadata can not be
modified, and the file can not be opened in write mode.
Only the superuser or a process possessing the
CAP_LINUX_IMMUTABLE capability can set or clear this
attribute.
So you essentially block any program trying to write it?
Yes. There’s software, like dhcp clients, that has claimed the right to automatically edit this without leaving a trace. It’s really hard to turn off, it’s easier to just ban this behavior categorically, if your use case is not the one in which this behavior is useful.
Re:Some ways DNS can break
by octoberfranklin on Monday January 17, 2022 @05:30PM
(#29972418)
This. I find it inexcusable that the Debian udhcpc package still does not provide any configuration option to inhibit it from overwriting /etc/resolv.conf.
The only option is to replace the "execute this when DHCP reply is recieved" script, which is not a simple script at all. And then you're stuck three-way-merging your changes to that script with every security update.
Re:Some ways DNS can break
by hackeraccount on Monday January 17, 2022 @09:07AM
(#29966656)
yeah that breaks my fucking VPN which won't start unless it can overwrite resolv.conf.
So now I have a job that watch for that and does a bind mount to make everything work.
Re:Some ways DNS can break
by octoberfranklin on Monday January 17, 2022 @05:30PM
(#29972421)
Get a better VPN, like wireguard.
Indeed. This was a good post a while back on just this issue:
We've come a long way from good ole fashioned libc/glibc acting as a good ole fashioned stub resolver on my UNIX system. Is systemd even looking at /etc/resolv.conf anymore? Who is overwriting /etc/resolv.conf? Is the information provided via DHCP being ignored? Is Firefox using DoH? Where is caching happening? How do I clear it?
All of these questions have completely different answers depending on OS and how they're configured. I work with OSX, Debian, Redhat and OpenBSD on the regular and they all have different answers for the above questions.