search

systemd / systemd

The systemd System and Service Manager
https://systemd.io
GNU General Public License v2.0
13.25k stars 3.79k forks source link

systemd-resolved: Global DNS configuration API #33754

Open pemensik opened 3 months ago

pemensik commented 3 months ago

Component

systemd-resolved

Is your feature request related to a problem? Please describe

I would like to have external specification of global DNS over TLS configuration, which I want to use for any connection and any wireless network. I would like to have a way to set it from Network Manager, in similar way to VPN.

I can already set DNS, DNSOverTLS and other parameters. But it is not possible to set similar values from trusted services. NM would be good example. It could have multiple possible DNS configured, but only one active. But it has no way to tell them to resolved. It seems only file source is possible for global parameters or defaults.

Describe the solution you'd like

I would like to have external definitions of globally used servers possible. Stored in unsupported format or obtained from different daemon. Example might be cloud-init interaction. DNS over TLS servers might need extra parameters like remote hostname or certificate authority to use at remote side.

Similar to resolvectl dns eno0 1.1.1.1, I would like to be able to set global DNS. Both using DBus API and command line. For example resolvectl dns * 1.1.1.1.

NetworkManager can already define global DNS, athough somehow crude way:

[global-dns-domain-*]
servers=8.8.8.8#dns.google

[connection]
connection.dns-over-tls=2

But it has no way to instruct systemd-resolved to use such servers. Even if nothing better is specified in resolved.conf configuration.

Describe alternatives you've considered

The systemd version you checked that didn't have the feature you are asking for

No response

pemensik commented 3 months ago
pemensik commented 3 months ago

Support for https://github.com/systemd/systemd/issues/33579 would be also nice. It should be possible to make difference between global DNS server mode and defaults for each link, unless specified explicitly. Especially "dns" default route should be more directly configurable.

poettering commented 2 months ago

Uh. the idea of resolved was that every tool that owns a netif can set its config on that, and doesn't end up fighting for the global dns server. Hence, I am not convinced this is desirable.

Having multiple downstream clients fight over a cerntral, singleton resource seems like a really bad idea.

pemensik commented 2 months ago

If support for multiple DNS over TLS profiles were added into Network Manager for example, there would be single place to define DoT servers, where only part of them would be activated. Quite similar to separate VPN connections.

It might be of course more restricted, which service is allowed to change global servers via API. Maybe once some service configures global servers, then only that is allowed to change them or unconfigure them. It should not be changed by as many as VPN connection settings. Maybe it should have extra ACL. But to become configurable via GUI, I think setting also global server by API is required also.

poettering commented 2 months ago

I don't get it. A global DNS server config is always just weird. Needs to be per-interface. Whener DoT, or DoH or classic DNS is used is just a choice of protocol, and has no relevance on the scope.

pemensik commented 2 months ago

We have started investigating it, because of Zero Trust architecture requires encrypted DNS. And that DNS should not be set per link, but on any link protected laptop (or phone) can connect to. System-wide. It depends whether link is considered just wireless interface (unlike NM), or connection profile identified by SSID (like NM does). Think about wifi, not ethernet cable port, to get what I mean. Microsoft article may help explain what that is about: https://techcommunity.microsoft.com/t5/networking-blog/announcing-zero-trust-dns-private-preview/ba-p/4110366 or https://techcommunity.microsoft.com/t5/networking-blog/deployment-considerations-for-windows-ztdns-client/ba-p/4113372.

The thing with encrypted DNS is user usually wants it to become default for all networks he or she visits. There might be exceptions for hotel reception or local office printer, but in general they want to avoid using all network services they can avoid. Instead use trusted and verified service instead. It is about the trust for networks connected into, which is considered low. Whatever machine administrator has configured is more trusted and should be more preferred. Only when for example captive portal needs to be done via local DNS server, then only needed queries are directed to it. So we cannot just drop link server information, but limit when it is needed to minimum, where it still works.

Note: private DNS on Android cannot be set per-connection, but only system-wide.

pemensik commented 2 months ago

Added also request to NM for multiple profiles of DNS servers. Upon activation, it might push via this API the active configuration into systemd-resolved. When deactivated, it may clear it and switch back to link interface. I think it would allow editing DNS properties in a nice graphical way. Not some text files common people cannot edit or understand.

poettering commented 2 months ago

What I'd be fine with, if we'd have an API to allow explicit allocation of additional resolved "scopes", that basically package a set of dns server addresses and routing domains together, and then are considered when looking up things the same way as the scopes currently synthesizes for each interface.

With that, you could implement something like you want: i.e. as long as NM runs it could allocate a scope that configures the dns servers it wants, as well as a ~. routing domain. This would mean it would be the preferred target of all lookups not routed everywhere, trumping the system or fallback DNS servers. It could also destroy the scope again.

This wouldn't be a singleton though, any local priv tool could allocate that.

poettering commented 2 months ago

oh, and regarding captive portals, we probably should have an explicit concept in resolved that scopes can be kept in a mode that ensures they are only accessible to clients marked specially, i.e. that are responsible for bringing the captive portal UI to screen and that go away once we are properly connected. That way NM or so could set up a scope in resolved, with lax encryption settings, but only accessible to captive portal tools, and once that stuff is complete, switch to a stricter mode (or disable the thing entirely, and instead allocate one of these dynamic scopes)