This post is simply wrong. Even on a plain old Debian without any of those programs (networkmanager, ...), the file /etc/resolv.conf will probably be written over at boot time. I don't want to draw a political comparison to the Brexit, but before engaging in "taking back control", one should learn how the current situation works and what the change will bring.
The main missing concept in the article is DHCP. Most computers use this to get their IP and the DNS servers. For example, for as long as I can remember the default Debian way to handle the network was ifupdown, where a hook called `dhcp` after an interface is connected, and by doing so the file resolv.conf is updated. If resolv.conf is manually controlled, there is no DHCP to update it, and then you have to declare your DNS servers. But the DNS that you can query from home may not be reachable from a public wifi. And at work, you won't have access to the intranet unless you add some private DNS servers at the top of your resolv.conf. So a totally manual handling of resolv.conf is a bad idea, at least for a laptop.
The article also never wonder why do all these programs try to "take control" of resolv.conf. Some of them just try to update it when they receive DHCP data about DNS. Other, like resolvconf, try to separate the manual part from the dhcp-generated part (which is what "manual control" should aim to). Other programs may add features, like a local cache or automatic knowledge of the local network (containers and such).
Sometimes you don't want to blindly trust dhcp. My isp is set up so that the internet-facing host gets an IP through dhcp. I don't want to use the ISP's dns however.
I use OpenBSD on that machine. I think it was "ignore domain-name-servers" in dhclient.conf that fixed that for me.
Careful. Even if you point at a different dns resolver, your ISP still gets to see this traffic, and it can still MITM it. This is not theoretical, it is trivial. Many ISPs do it.
Confidentiality isn't the only form of trust, many are simply annoyed with "features" such as wildcard catch-alls that direct you to ad/search pages instead of saying the domain doesn't resolve.
I've seen no evidence that Virgin Media intercepts UCP/TCP port 53 traffic, however. It just runs rigged proxy DNS servers and farms them out over DHCP.
I've seen several reports that the Virgin Media "click here to disable" mechanism is a placebo that actually does nothing at all, including what that message was a reply to.
I use non-ISP dns servers for a variety of reasons. I've tested and found 1.1.1.1 faster than my ISP dns in the past.
Some people use e.g. opendns because they want to use that for keeping track of what dns names are being queried from inside their networks.
I actually do use my ISP's dns for some names (particularly netflix), because only they know the names of their internal cache boxes. I have a dnsmasq configuration that sends queries that end in `netflix.com` to the ISP dns and others to 8.8.8.8/1.1.1.1 or whatever.
Actually unbound. I forget why I chose this over unwind. I had a reason once. Set it up years ago and didn't touch the config files. Maybe the initial setup predated unwind and I had something working already...?
Totally off topic, but I was thinking of replacing it with something I wrote myself. I had some downtime earlier this year and I wrote a forwarding dns server that can speak TLS on both ends. Was simple to do. But needs some polishing before I throw it on github or use it at home.
dnsmasq, unwind and others all support DNSSEC
If you can get a DNS path with DNSSEC, this bypasses the ISP's ability to manipulate your DNS.
Of course, DNS over HTTP is another solution to the same, for browsers.
Of course one could also tunnel through.
It doesn't matter how much of your own software supports DNSSEC: if the sites you talk to on the Internet don't explicitly support it, DNSSEC does nothing for you. This is a problem, because most sites on the Internet don't support it. Several of the most important sites on the Internet, with some of the largest security teams in the industry, have said they don't intend ever to support it.
On the other hand, DNS over HTTPS defeats ISP DNS interception regardless of who supports it, which is why so many more people use it than use DNSSEC, which is moribund.
Here is what I do to take back control of host resolution which was probably the intended goal.
First of all, /etc/nsswitch.conf set the priorities. For instance the line `hosts: files myhostname mymachines dns` would exclude systemd-resolved (aliased to `resolve`) and try to identify containers before querying DNS. See the man.
I used to use resolvconf in order to merge my local rules with those set automatically by DHCP. Nowadays I have a dnsmasq daemon running a dns proxy. This way I can set rules so that some domains are linked to special DNS (e.g. *.debian.org should be resolved through 1.1.1.1 instead of the default that the DHCP set). And added benefit is the filtering of ad domains.
The main missing concept in the article is DHCP. Most computers use this to get their IP and the DNS servers. For example, for as long as I can remember the default Debian way to handle the network was ifupdown, where a hook called `dhcp` after an interface is connected, and by doing so the file resolv.conf is updated. If resolv.conf is manually controlled, there is no DHCP to update it, and then you have to declare your DNS servers. But the DNS that you can query from home may not be reachable from a public wifi. And at work, you won't have access to the intranet unless you add some private DNS servers at the top of your resolv.conf. So a totally manual handling of resolv.conf is a bad idea, at least for a laptop.
The article also never wonder why do all these programs try to "take control" of resolv.conf. Some of them just try to update it when they receive DHCP data about DNS. Other, like resolvconf, try to separate the manual part from the dhcp-generated part (which is what "manual control" should aim to). Other programs may add features, like a local cache or automatic knowledge of the local network (containers and such).