Editing resolv.conf no longer changes my DNS servers — what replaced it?

The loopback address in resolv.conf is the clue: your system is running a local stub resolver, and /etc/resolv.conf is now a generated file pointing at it rather than a configuration file you own.

On most current systemd-based distributions that resolver is systemd-resolved. The chain is:

1. Applications read /etc/resolv.conf.
2. That points at the local stub listener.
3. The stub forwards to whatever upstream servers it has been configured with.

So editing step 1 changes nothing meaningful, and the file gets regenerated because it is an output.

The correct place to make the change is the resolver's own configuration — /etc/systemd/resolved.conf, where you set the DNS= line to your chosen upstream servers, then restart the service. After that, resolvectl status will show you the upstream actually in use, which is the command to trust rather than reading the file.

If you specifically want to take manual control and stop anything managing it, that is a legitimate configuration and it is worth doing deliberately rather than by fighting the tooling.

The general shape is: disable or mask whichever manager is writing the file, replace the symlink with a real file, and put your servers in it. On systems using the stub resolver, /etc/resolv.conf is a symlink into a generated directory — replacing the symlink is the actual step people miss, because editing through the symlink edits the generated file.

Be aware of what you give up. The stub resolver provides caching, per-interface DNS and DNSSEC handling. On a VPS with a single interface you probably do not care. On anything with a VPN, you will care immediately, because split DNS stops working and you lose name resolution for internal hosts the moment the tunnel comes up.

Worth knowing there are usually three possible managers on a server, and which one you have determines the answer:

• systemd-resolved — the stub listener case above. Configure in resolved.conf.
• NetworkManager — common on desktops and some server images. It writes resolv.conf from the connection profile, so configure the connection, not the file.
• The DHCP client — on a plain server image with neither of the above, the DHCP client overwrites resolv.conf on every lease renewal with whatever the network handed you. That is why your edits survive for a while and then vanish.

The quickest way to tell which you are dealing with: look at the first line of /etc/resolv.conf. It almost always contains a comment naming the program that generated it. That one line saves a lot of guessing.

One verification habit worth adopting: do not test with the tools that bypass the system resolver.

dig and nslookup talk to a nameserver directly and will happily give you a correct answer that has nothing to do with what your applications experience. getent hosts <name> or resolvectl query <name> goes through the actual system path.

More than half the "I changed it and it still does not work" reports I have seen are somebody testing with dig against the old server out of habit.