Re: DNS over TLS connection setting providers

2022-10-17 Thread Thomas Haller via networkmanager-list
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 

DNS over TLS connection setting providers

2022-10-15 Thread Petr Menšík via networkmanager-list

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


What do you think about that? Is even NM able to start or stop services? 
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?


Is there any plan to configure per-connection configuration of SNI names 
for TLS services? 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?


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


Regards,
Petr

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list