this post was submitted on 20 Oct 2023
145 points (89.6% liked)

Linux

48343 readers
397 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
145
Linux DNS settings is a total mess (lemdro.id)
submitted 1 year ago by [email protected] to c/[email protected]
68 comments fedilink hide all child comments
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 6 points 1 year ago (2 children)

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.

[–] [email protected] 4 points 1 year ago (1 children)

This is terrible. At least they should deprecate that file.

[–] [email protected] 5 points 1 year ago (1 children)

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.

[–] [email protected] 2 points 1 year ago (1 children)

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 local systemd-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.

[–] [email protected] 2 points 1 year ago

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.

[–] [email protected] 4 points 1 year ago

Cloud-init is fairly well documented:

https://cloudinit.readthedocs.io/en/latest/reference/network-config-format-v2.html#nameservers-mapping

But if you do not need it (and if you're configuring DNS by hand, it doesn't sound like you do), you can disable it entirely:

https://cloudinit.readthedocs.io/en/latest/howto/disable_cloud_init.html

resolv.conf itself should be managed by systemd-resolved on any modern Ubuntu Server release. And that service will use the DNS settings provided by netplan.

With cloud-init disabled, you should have the freedom to create/edit configuration files in /etc/netplan and apply changes with netplan apply.