3 ms·

My proposal. $ cat /etc/resolv.conf # DO NOT EDIT THIS FILE. This file is currently under the management # of NetworkManager. It's automatically g

My proposal. $ cat /etc/resolv.conf # DO NOT EDIT THIS FILE. This file is currently under the management # of NetworkManager. It's automatically generated according to the # DNS configuration of the active network connection in NetworkManager. # Any change to this file will be overwritten. # # If you are trying to change your DNS resolver, it's officially recommended # to set it within NetworkManager on a per-connection basis via "nmtui", "nmcli", # or alternatively, by editing files under "/etc/NetworkManager/system-connections/". # # To stop NetworkManager from managing it altogether, edit # /etc/NetworkManager.conf, set the following and # restart NetworkManager, before you edit /etc/resolve.conf. # # [main] # dns=none # # If you are trying to set up a stub DNS resolver, it's recommended to # invoke NetworkManager's builtin support. Set "dns=dnsmasq" or "dns=unbound" # # See "man 5 NetworkManager.conf" for more details.

JdeBP 6y ago
I recommend reading RFC 1034 section 5.3.1 first, and learning what a "stub resolver" actually is. It's actually the thing that is reading /etc/resolv.conf . * https://unix.stackexchange.com/a/500565/5132 https://unix.stackexchange.com/a/500565/5132
- vetinari 6y ago
  Reading up about glibc's nsswitch would also help. The problem with RFC 1034 section 5.3.1 ideas is, that it is insufficient if you have more than 1 interface and DNS resolvers available over them might provide different answers for some zones (example: you have a VPN connection and the DNS resolver on the other side of the link has ACLs for the zones it is handling, providing you with answers that the public DNS won't provide); that's why networkmanger+dnsmasq/systemd-resolved/whatever are used. Linux is not the only system that has to handle /etc/resolv.conf being inadequte; but it is funny that we see articles like this only for Linux. I have yet to see an article "How to take back control of /etc/resolv.conf on MacOS".
  - JdeBP 6y ago
    That's because there actually is a comment in /etc/resolv.conf on MacOS telling you that it isn't used by the libraries there. This is ironic, given the context here. # # Mac OS X Notice # # This file is not used by the host name and address resolution # or the DNS query routing mechanisms used by most processes on # this Mac OS X system. # # This file is automatically generated. # /etc/resolv.conf hasn't been the place for this for the past 17 years, this having changed in MacOS 10.3. It's in the system preferences plist now, modifiable with the networksetup tool. And you've clearly never seen https://community.cleanbrowsing.org/knowledge-base/change-dns-nameserver-on-a-mac-terminal/ https://community.cleanbrowsing.org/knowledge-base/change-dn... or its ilk. (-: I'm pointing out that unbound, dnsmasq, et al. are not "stub resolvers", by the way.
    - vetinari 6y ago
      No, I've never seen cleanbrowsing and it's ilk; at least in this case it is a comercial companies trying to force the system to work with their product, not a part of community supposedly "fixing" the system and breaking it in process. They also do not force resolv.conf, only using the new configuration mechanism to make their changes stick. Unbond & co are of course not stub resolvers; however the classic stub resolvers (like glibc nss dns module) are kind of obsolete too. All modern systems have an service, that does the resolving and caching in the separate process and the nss just asks that process. Just like unbound & co. With properly configured nsswitch (e.g. with system-resolved and nss-resolve), the resolv.conf is not used either, just like with MacOS. Resolv.conf pointing to local resolver is only for processes, that ignore nsswitch and would be break otherwise.

JdeBP 6y ago

I recommend reading RFC 1034 section 5.3.1 first, and learning what a "stub resolver" actually is. It's actually the thing that is reading /etc/resolv.conf . * https://unix.stackexchange.com/a/500565/5132 https://unix.stackexchange.com/a/500565/5132

vetinari 6y ago
Reading up about glibc's nsswitch would also help. The problem with RFC 1034 section 5.3.1 ideas is, that it is insufficient if you have more than 1 interface and DNS resolvers available over them might provide different answers for some zones (example: you have a VPN connection and the DNS resolver on the other side of the link has ACLs for the zones it is handling, providing you with answers that the public DNS won't provide); that's why networkmanger+dnsmasq/systemd-resolved/whatever are used. Linux is not the only system that has to handle /etc/resolv.conf being inadequte; but it is funny that we see articles like this only for Linux. I have yet to see an article "How to take back control of /etc/resolv.conf on MacOS".
- JdeBP 6y ago
  That's because there actually is a comment in /etc/resolv.conf on MacOS telling you that it isn't used by the libraries there. This is ironic, given the context here. # # Mac OS X Notice # # This file is not used by the host name and address resolution # or the DNS query routing mechanisms used by most processes on # this Mac OS X system. # # This file is automatically generated. # /etc/resolv.conf hasn't been the place for this for the past 17 years, this having changed in MacOS 10.3. It's in the system preferences plist now, modifiable with the networksetup tool. And you've clearly never seen https://community.cleanbrowsing.org/knowledge-base/change-dns-nameserver-on-a-mac-terminal/ https://community.cleanbrowsing.org/knowledge-base/change-dn... or its ilk. (-: I'm pointing out that unbound, dnsmasq, et al. are not "stub resolvers", by the way.
  - vetinari 6y ago
    No, I've never seen cleanbrowsing and it's ilk; at least in this case it is a comercial companies trying to force the system to work with their product, not a part of community supposedly "fixing" the system and breaking it in process. They also do not force resolv.conf, only using the new configuration mechanism to make their changes stick. Unbond & co are of course not stub resolvers; however the classic stub resolvers (like glibc nss dns module) are kind of obsolete too. All modern systems have an service, that does the resolving and caching in the separate process and the nss just asks that process. Just like unbound & co. With properly configured nsswitch (e.g. with system-resolved and nss-resolve), the resolv.conf is not used either, just like with MacOS. Resolv.conf pointing to local resolver is only for processes, that ignore nsswitch and would be break otherwise.