Re: DNS over TLS connection setting providers

[Thomas Haller <thaller redhat com>]

hi Petr,


On Sat, 2022-10-15 at 21:41 +0200, Petr Menšík via networkmanager-list
wrote:
> Hi!
>
> I were traveling on a new train recently with working public wifi. 
> Because I use dns=dnsmasq on my laptop, I thought about new 
> connection.dns-over-tls setting I have discovered.
>
> I maintain also package stubby, which might be a great fit into 
> providing the service. Because dns over tls requires not only IP
> address 
> of dns server, but also its name obtained with secure enough way. But
> I 
> have not seen a way to specify it. 

DoT currently anyway only has an effect with systemd-resolved. But
being unable to specify the server name is a missing feature:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/528
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1434


> But I thought, what if I wanted just 
> primary forwarder to be directed to a service providing DNS over TLS,
> such as stubby? It configures forwarders, their names and certificate
> pins. dnsmasq might still provide ability to configure different
> domains 
> going to different server on connected LANs. But if NetworkManager
> had 
> option to send forwarder 127.0.0.83 when DNS over TLS setting is on,
> it 
> could provide per connection ability to use DNS over TLS over
> untrusted 
> networks, but use plain UDP queries on trusted networks.
>
> To work, it would require:
>
> - manual configuration of stubby service to listen on alternative 
> address 127.0.0.83, not on default localhost
> - Network Manager should start stubby.service after connection
> requiring 
> dns over tls is activated. It might be possible to auto-start it by
> some 
> systemd feature, but I think it won't know when it is no longer 
> necessary this way.
> - Network Manager would replace DNS obtained from DHCP with stubby's 
> address only on connections setting dnsovertls=yes.
> - Network Manager should stop stubby.service after all connections 
> requiring it are disconnected.
>
> I think it would require two new configuration options in 
> NetworkManager.conf:
>
> dnsovertls_ip=127.0.0.83 # whatever IP to use when it is activated
> dnsovertls_service=stubby # what service to start and stop on
> connection 
> activation
>
> While I think here about dnsmasq and stubby combination, it might
> work 
> also with different provider. I think dnscrypt might be possible 
> example, altough I have never used it.

in /run/ there are two files:

  /run/NetworkManager/no-stub-resolv.conf
  /run/NetworkManager/resolv.conf

no-stub-resolf.conf contains the actual name servers (that NM would
configure also in dnsmasq/systemd-resolved).

When using a `[main].dns` plugin (dnsmasq/systemd-resolved), then
"resolv.conf" usually just contains 127.0.0.1/127.0.0.53.

-- granted, in a common setup with systemd-resolved, /etc/resolv.conf
is a symlink, and NetworkManager wouldn't actually write that file (due
to `[main].rc-manager=symlink` setting). But it still writes the
internal /run/NetworkManager/resolv.conf.

Anyway, there is precedence to writing localhost to resolv.conf.
Except, it's not configurable much:

- `[main].rc-manager` determines whether /etc/resolv.conf is written
(but not *what* is written).
- whether you have a DNS plugins, determines whether the nameservers in
resolv.conf are redirected to localhost.



> What do you think about that?

Sounds compliated :)

> Is even NM able to start or stop services? 

NM would be able to start services via systemd.

NM currently never directly talks to systemd, and we were always
reluctant to add a feature that has such a dependency. Instead,
NeworkManager uses D-Bus activation (with wpa_supplicant, systemd-
resolved), requires the service already running (bluez, ModemManager)
or spawns it themselves (teamd, dnsmaq). (Spawning processes ourselves
is highly problematic and should be avoided).


> Should it even attempt to control some? Are there some alternatives, 
> except using systemd-resolved only? I understand it manages its own 
> configuration per interface. I think other implementations do not
> allow 
> that. Would it make sense to simplify per-connection setting of
> secured 
> DNS also in UI?

How woud you simplify the UI?

The UI just mirrors the main configuration concept of NetworkManager:
that you have connection profiles with configuration, which you
activate/deactivate.

With NetworkManager, if you don't think about "connection profiles",
it's not clear how such an API could look (or a UI).

> Is there any plan to configure per-connection configuration of SNI
> names 
> for TLS services?

I think, the SNI should be "attached" to the configuration where the
DNS server lies. Above MR extends the `ipv4.dns`, `ipv6.dns`
properties, which however only works for manual, per-profile DNS
settings.

If you get the DNS server from DHCP, etc, then above MR cannot set the
SNI.

> Like dns.google for 8.8.8.8? I am not sure most user 
> needs it configured per connection, few profiles in one system might
> be 
> enough. Has NetworkManager abilities or permissions to start or stop 
> selected services? Should it try to do so? Are there other variants?

For something like 8.8.8.8, that seems a very "static" configuration.
Maybe in that case, it would be enough that the DoT resolver (systemd-
resolved) has a global list with known-fallback-SNIs?

In any case, there could also be a new "dns-over-tls-default-sni"
property in NetworkManager (again per-profile).


> I were thinking about creating pull request, but I think I understand
> possibilities of NM already.


Make sense. In general, I am reluctant to personally invest effort into
providing alternative solutions to systemd-resolved, because having
multiple ways to do things increases the complexity exponentially. We
will end up with multiple solutions that all have their own problems,
instead of investing the few resources we have into making one solution
work really well.

Having said that, those who contribute patches have a strong say in
what gets implemented and we (the maintainers) would not reject a
reasonable feature.


Thomas