Hi David, more below. On 2/25/21 11:57 AM, David Sommerseth wrote: > On 22/02/2021 16:29, Petr Menšík wrote: >> Why? I thought about common interface to various DNS cache >> implementations for workstations and different VPN providers available. >> While I think the best place to direct, which interface resolvers should >> handle given domains. resolvconf handles conflicting requests from >> different interfaces, when multiple DNS resolver providers are >> configured by connection. > > Just providing some input from the OpenVPN perspective. > > * OpenVPN 3 Linux > > OpenVPN 3 Linux [0] since the v10 release provides native > systemd-resolved support > > It is not optimal yet, but we plan to provide full support for split-DNS > (only pushed domains will be resolved via the DNS server requested by > the VPN server) and exclusive DNS (use only the DNS server pushed by VPN > server). This case is exactly what I am trying to prevent. There is multiple implementations of dns cache, most of them can support split-DNS by some configuration. If openvpn supports systemd-resolved natively, does that mean it would not be able to support split-DNS on dnsmasq or unbound? What is motivation to support specific implementation instead of generic interface? I don't want to ask openvpn to support also dnsmasq or unbound natively, because I think there should be middle layer support. I am trying to use resolvconf as such layer. I am dnsmasq, unbound and bind (co)maintainer. I want them to stay first class citizens in Fedora, even when they are not installed by default. Of course, also knot-resolver and pdns-recursor should be supported, if they are (willing and) able to. > > The current implementation will query all DNS servers on all interfaces. > This hybrid mode will also be supported. > > At the moment I'm not yet decided what should be the default mode, but > I'm leaning towards split-DNS - as that provides the least risk for DNS > leakage either way. But for some any DNS lookups to the main link is > considered a DNS leak as well, so this is highly usage dependent. We > are also considering how far the server can go to push for a certain > profile - as the use cases for VPN provider side are also very diverse > with different requirements. I think it should be configurable from server side with ability to override it on client side. The VPN owner should be able to do specify, whether all queries or only domain-selected queries should go over the VPN. Is it already possible to choose the variant from server side? The default should matter only in case VPN administrator does not care. > > For the v10+ releases you need to do a little configuration step [1] to > enable this support, but we are planning to enable this by default on > Fedora 33+. Ubuntu 20.04 will probably also be updated to use it by > default. This will most likely happen from the v14 release. > > > * OpenVPN 2.x > > We are also considering to fully embrace the update-systemd-resolved [2] > script for the OpenVPN 2.x versions. And will work together with this > project to ensure OpenVPN 3 Linux and OpenVPN 2.x will behave a similar > as possible. Is there a reason, why systemd-resolved's resolvconf does not work for you? Does update-systemd-resolved need more functionality than resolvconf is able to provide? Was the reason missing resolvconf on Ubuntu/Debian? For example, resolvconf -p -a <resolv.conf would request only selected domains over provided interface. resolvconf -x -a <resolv.conf would send all queries over the interface, according to man 8 resolvconf. The same seems to be supported also by systemd's resolvconf. Was resolvconf usage tried for this purpose? AFAIK systemd does not provide resolvconf on Ubuntu nor Debian, where only openresolv and resolvconf packages exist to provide resolvconf binary. In Fedora, only systemd provided it until now. I think resolvectl might expose resolvconf interface via parameters, not only by resolvconf symlink to resolvectl. It misuses search resolv.conf clause to list provided domains a bit. I doubt ~domain notation is supported by openresolv already, but I think it would not be hard to implement it. > > > * NetworkManger and OpenVPN > > Outside of that, OpenVPN via NetworkManager will be a different beast to > tackle which we have not yet dug into from the OpenVPN project side. > From the OpenVPN side, we are not too happy about the current > NetworkManager plug-in from a general point of view. > > It is good with the graphical interface, but NetworkManager does not > fully consider what OpenVPN is capable and restricts its capabilities > too much in several areas (like killing the OpenVPN process if the main > link disappears; OpenVPN is capable of recovering quite nicely when > network recovers). And we have more OpenVPN specific features planned > as well, where the NetworkManager can cause more damage - as it does not > (and should not) understand how OpenVPN operates. > > * DNS updates > > If NetworkManager is capable of fully integrating with a unified DNS > resolver management which OpenVPN and other updateresolve alternatives > could work with would definitely be the best for all of this. NM can set ipv4.dns-search and ipv4.dns, with ipv6 having this too. My ethernet nmcli shows values from DHCP as IP4.DNS[*] and IP4.DOMAIN[*]. I think that is almost all we need. Set of DNS IPs and list of domains handled by them. Then just a signal of preference, whether to forward all unspecific queries to this connection by default. NM has also ipv4.dns-priority number, I guess it is for similar thing. Problem is as you already noted, NM limits some feature uses. I think NM can store only values per connection only when it manages such connection. I doubt it can store dns properties on connections or devices not managed by it. resolvconf should make possible even pure openvpn connections having list of dns servers and list of domains. Can or should we ignore connections not managed by NM? How rare are they? > > OpenVPN 3 Linux and OpenVPN 2.x can be extended and taught to integrate > with various DNS management approaches. systemd-resolved is already on > the way, but does not need to be restricted here. But we are very much > interested in being involved in such discussions. Of course! Providers of VPN are a primary target to split-DNS support. There should be unified interface for them, without having to implement any specific cache details. Implementation-specific mapping to cache implementation should be provided by dns cache maintainers IMHO. If resolvconf is problematic in any way, what features are missing? What requirements are important for OpenVPN? Is OpenVPN 3 even packaged on Fedora? > > > [0] <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux> > [1] > <https://www.mail-archive.com/openvpn-devel@xxxxxxxxxxxxxxxxxxxxx/msg20607.html> > > [2] <https://github.com/jonathanio/update-systemd-resolved> > > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@xxxxxxxxxx PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
