Hacker News Reader

Comment by jeroenhd | Hacker News Reader

Resolve.conf is a blessing and a curse. On the one hand, you've got a file that nearly every flavour of Linux will use for DNS resolution with a standardised format. On the other hand, you've got four hundred network managing programs that all need to be told separately that you don't want to use them to manage the file for you because you want to set it up yourself.

Makes me wonder if the file options should be extended contain a config option to indicate what program manages the file so that others know to keep their hands off. Right now there's comments in there, but those comments are often hardly machine readable.

View on HN

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.

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

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".

The handling for the resolv.conf file is embedded in the libc and is larger than Linux. This whole issue is a failure of the Linux distribution community to come up with coherent standards for managing a simple text file on a system using DHCP. The solutions today are horribly complicated and appear to optimize for laptop users on simple, naive networks. I have no idea why I have to mess with any of this garbage on my servers.

No, we need to get back to software like it was in the early 2000s when people cared about consistent, long-term behavior instead of re-inventing everything because laptops.

It makes sense to me. It solves the problem for simple networks and roaming users - so basically situations where things are expected to "just work" with minimal knowledge. It's our (sysadmins) job to configure the system correctly in other places. Especially in case of weird networks.

But simple networks and roaming users are perfectly fine with regular static file. I have no idea what user base this overengineered crap is catering but it seems equally useless both on (my) servers and laptops.

> roaming users are perfectly fine with regular static file.

If you want them to have broken DNS, then they are fine. If you want them to have working DNS, then not, regular static file is not fine.

A significant number of hotels do the login portals using their own DNS servers, do if you ignore those, you can't use that network. Pretty much every corp environment forces local DNS servers.

The web portal isn't the only way on to a hotel network, just the most convenient. The Nintendo Switch console doesn't support captive portals either, so I've gotten in the habit of dialing the front desk any time I stay at a hotel and asking to be transferred to the network team. You tell them you need a device whitelisted and provide your room number, duration of stay, and the MAC of any devices.

This may work in a large hotel chain, but not in a b&b which licenses their it solution from a 3rd party that never wants to speak with you.

resolv.conf never worked for roaming users. glibc famously only read it on application startup.

I disagree, this is historical baggage that /etc/resolve.conf is both configuration and runtime state and so any solution will be a little awkward.

If you only let one thing on your system own it: NetworkManager, dhcpcd, systemd-resolved, netplan, ifcfg, $you then it’s no issue.

Run those programs under different users and make it writeable only for those programs that have permission to modify it.

chattr +i will tell them impolitely to f-off.

Reply on news.ycombinator.com