I recently tried to enable system-wide DNS over https on Fedora. To do so I had to to some research and found out how comfusing it is for the average user (and even experienced users) to change the settings. In fact there are multiple backends messing with system DNS at the same time.
Most major Linux distributions use systemd-resolved for DNS but there is no utility for changing its configuration.
The average user would still try to change DNS settings by editing /etc/relov.conf (which is overwritten and will not survive reboots) or changing settings in Network Manager.
Based on documentation of systemd-resolved, the standard way of adding custom DNS servers is putting so-called ‘drop-in’ files in /etc/systemd/resolved.conf.d directory, especially when you want to use DNS-over-TLS or DNS-over-https.
Modern browsers use their buit-in DNS settings which adds to the confusion.
I think this is one area that Linux needs more work and more standardization.
How do you think it should be fixed?
The average user would still try to change DNS settings by editing /etc/relov.conf (which is overwritten and will not survive reboots) or changing settings in Network Manager.
No. The average user would use NetworkManager GUI integrated into DE.
Network Manager doesn’t support DOH.
The average user barely know what is DNS, so DoH…
Android supports DoT, and it can be easily configured by the user. They call it ‘Private DNS’ though, in order to not confuse users with terminology like ‘DNS-over-TLS’. Also most browsers support DoH, Chromium just calls it ‘Secure DNS’, again, in order not to confuse users. NetworkManager could definitely implement DNSCrypt, DoT and DoH, maybe even DoQ and just call it ‘Encrypted DNS’ and add a toggle to choose the protocol.
I don’t think systemd-resolved has support for DNS-over-HTTPS yet but it has support for DNS over TLS which I have used issue free for years now.
All the browsers will use your system configured DNS if you do not touch the browser’s DNS settings.
DNS is not broken on Linux, your configuration is.
All the browsers will use your system configured DNS if you do not touch the browser’s DNS settings.
Not necessarily. Firefox ships with its own DoH enabled out of the box, which uses Cloudflare servers.
Then Firefox is broken in this context. It should respect the user’s system DNS settings.
Edit: You are wrong. The correct answer is somewhere along the lines of borderline confusing and you don’t have to worry about it if everything is working. In my case, it used my DNS provider set by systemd-resolved and not cloudflare but YMMV.
This is what the default menu for Firefox DNS settings say:
Enable secure DNS using: ... Firefox decides when to use secure DNS to protect your privacy. Use secure DNS in regions where it’s available Use your default DNS resolver if there is a problem with the secure DNS provider Use a local provider, if possible .... Turn off when VPN, parental control, or enterprise policies are active Turn off when a network tells Firefox it shouldn’t use secure DNS
Firefox DoH has been enabled by default for the US for a couple of years now.
The US is not the world!
And neither Firefox nor its broken? DNS implementation have anything to do with the topic(Linux DNS)…
You said all browsers would follow your system DNS, I just explained that’s not always the case.
And there is actually a common problem with devices on the LAN that use DoH. You can block their access to the specific DNS servers they use, or block their access to the internet altogether, but you can’t force them to use your DNS settings.
You said all browsers would follow your system DNS, I just explained that’s not always the case.
Both Firefox & Chrome follow my system DNS at default settings. Just because Firefox forcefully enrolled US users to Cloudflare’s DOH doesn’t mean that DNS is broken for every one else.
And there is actually a common problem with devices on the LAN that use DoH. You can block their access to the specific DNS servers they use, or block their access to the internet altogether, but you can’t force them to use your DNS settings.
Again. Has nothing to do with the topic i.e Linux DNS. Applications can use their own custom DOH/DOQ resolvers to bypass system DNS, this has no bearing on the brokeness or not of systemd-resolved or any other system DNS resolver.
I just edit
resolv.conf
directly, and then dochattr +i /etc/resolv.conf
to make it persistentSystemd likes to ruin all the easy stuff with overcomplicated bloated programms.
I don’t touch my fedora DNS settings because my openwrt router handles DoT for the entire network.
That doesn’t help outside of home. When we are in an untrusted network then the DNS mess makes us vulnerable for spoofing attacks.
deleted by creator
Could also look at tailscale, set it up on you home PCs and mobile devices, set the magic DNS to a home server or vps running pihole. If you don’t like the aspect of tailscale being controlled by a third party you could self host that part using headscale on docker as well
No software should EVER touch any DNS related configuration or file and no application should bring it’s own system for DNS request. Everything regarding DNS without any exception should be done by the application that sets up and handle the network connection.
No software should EVER touch any DNS related configuration
Uhh good luck with that. If it were stored on magnetic media I’d suggest “a magnet and a very steady hand” but that doesn’t work so much for SSDs.
It’s very easy when not using systemd-resolved.
You haven’t used Ubuntu Server… The resolv.conf is managed by the network manager (NetworkManager if I recall correctly). But if you configure the DNS in NM it won’t survive the reboot because there is another layer on top, cloudinit.
This is terrible. At least they should deprecate that file.
Can’t, it’s hardcoded by too many programs out there.
resolv.conf
is still the place to get DNS configuration, but it was hijacked by various “helping” tools so you can’t edit it manually anymore. Why they couldn’t stick to adding/etc/resolv.d/*.conf
files like to many other /etc/ stuff, I’ll never know.You basically just made the case for exactly why.
Programs should be using the system resolver, not parsing that file.
The system resolver should have predictable behavior. But if other programs are doing their own DNS resolution (or otherwise predicating their functionality) based directly on the contents of
resolv.conf
then their behavior will not always be consistent with the system resolver (or with how the sysadmin intended things to function).And that can break things in subtle, unpredictable ways, which is always a headache.
Thus, on some modern systems,
resolv.conf
simply declares the localsystemd-resolved
instance (i.e. 127.0.0.1) and nothing else.A single global resolv.conf file also will not let you configure different behavior based on interface or on network namespace. Want to ensure DNS lookups for specific apps occur only through your VPN-specific DNS servers but all other apps only use the normal system resolvers (i.e. no leaking from either side of the divide)? Want to also ensure DNS lookups for those specific apps fail when the VPN is down (again, as opposed to leaking)?
systemd-resolved
has your back.And before anyone asks, yes, I am aware there are other, more crude and convoluted ways to do that with e.g. iptables (just like you can use crude, inconsistent init.d spaghetti scripts to manage services). It’s just one single real-world example.
A single global resolv.conf file also will not let you configure different behavior based on interface or on network namespace.
The point is to configure everything using consistent, predictable configuration files and syntax, and to ensure consistent, predictable behavior.
But if you ultimately still want
resolv.conf.d
back, then your distro of choice undoubtedly provides a way to do so.Programs should be using the system resolver, not parsing that file.
What’s a “system resolver”? We’re talking about DNS servers. You’re either running one locally or not. Either way, you need a way for everybody to know what DNS servers to use, regardless of whether you run one on the machine. That’s where resolv.conf comes in.
And that can break things in subtle, unpredictable ways, which is always a headache.
Let’s see some examples.
A single global resolv.conf file also will not let you configure different behavior based on interface or on network namespace.
Good, because that has nothing to do with DNS, it’s a matter of routing. They’re orthogonal issues.