GNOME Bugzilla – Bug 699810
dns: support for unbound with split DNS and DNSSEC
Last modified: 2020-11-12 14:31:04 UTC
We have long been talking about better DNS handling in NetworkManager. Currently, the dnsmasq plugin starts dnsmasq as part of connection activation, supports split DNS but doesn't support DNSSEC. I'm filing this ticket to record our ideas and post some architectural questions. Should the unbound plugin start the unbound daemon at runtime or should it use a long-running unbound daemon in the system and just reconfigure it? How would they communicate? Can unbound plugin do things like clean up part of the cache on reconfiguration, e.g. when I remove a split DNS domain that I no longer want it to cache the now obsolete information for that specific subtree (set of subtrees)? Same for the root tree because a user could move from malfunctioning network to a network with proper DNS? Do we need dnssec-trigger and what functionality it can provide? How do we integrate with changes made directly by other networking tools (like VPN services) not managed by NetworkManager if they choose to run such services on the system?
Created attachment 273517 [details] [review] Preliminary support for unbound Here's the first patch with a preliminary support for unbound and dnssec-trigger. To work properly, it needs the current Git version of dnssec-trigger and a released version of unbound.
Created attachment 273520 [details] [review] Updated patch (manpage text added)
Won't work because NetworkManager and dnssec-trigger-script block each other.
Created attachment 273578 [details] [review] Updated patch (use --async to avoid blocking)
There seems to be a bit of a race condition in NM: # journalctl -f /usr/libexec/dnssec-trigger-script -- Logs begin at Tue 2014-03-18 23:38:21 CET. -- Apr 18 19:39:01 localhost dnssec-trigger-script[4280]: copyfile(src, dst, follow_symlinks=follow_symlinks) Apr 18 19:39:01 localhost dnssec-trigger-script[4280]: File "/usr/lib64/python3.3/shutil.py", line 110, in copyfile Apr 18 19:39:01 localhost dnssec-trigger-script[4280]: with open(dst, 'wb') as fdst: Apr 18 19:39:01 localhost dnssec-trigger-script[4280]: FileNotFoundError: [Errno 2] No such file or directory: '/var/run/dnssec-trigger/resolv.conf.bak' Apr 22 21:41:24 localhost.localdomain dnssec-trigger-script[8397]: ** (process:8397): WARNING **: Error in get_property: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist Apr 22 21:41:24 localhost.localdomain dnssec-trigger-script[8397]: ** (process:8397): WARNING **: Unknown device type 0 Apr 22 21:41:24 localhost.localdomain dnssec-trigger-script[8397]: /usr/libexec/dnssec-trigger-script:60: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Apr 22 21:41:24 localhost.localdomain dnssec-trigger-script[8397]: self.__class__.nm_connections = self.client.get_active_connections() Apr 22 21:41:24 localhost.localdomain dnssec-trigger-script[8397]: /usr/libexec/dnssec-trigger-script:60: Warning: g_value_get_uint: assertion 'G_VALUE_HOLDS_UINT (value)' failed Apr 22 21:41:24 localhost.localdomain dnssec-trigger-script[8397]: self.__class__.nm_connections = self.client.get_active_connections()
Review of attachment 273578 [details] [review]: man/NetworkManager.conf.xml: has a trailing whitespace :) and could you mention in the manual, that in this mode /etc/resolv.conf will be rewritten by NM? + return nm_spawn_process ("/usr/libexec/dnssec-trigger-script --async --update") == 0; This calls the script synchronously, with the argument --async -- which probably sends the script in the background -- otherwise the script cannot communicate with the blocked NM. It would be more robust, to call the script asynchronously because obviously you don't need the synchrony behavior. I see, there is no nm_spawn_process_async() function... might be useful to add. The rest looks good to me -- as a first shot to introduce the new plugin.
(In reply to comment #6) > Review of attachment 273578 [details] [review]: > > man/NetworkManager.conf.xml: TODO > has a trailing whitespace :) > and could you mention in the manual, that in this mode > /etc/resolv.conf will be rewritten by NM? TODO It will be rewritten by dnssec-trigger called from NM. > + return nm_spawn_process ("/usr/libexec/dnssec-trigger-script --async > --update") == 0; > > This calls the script synchronously, with the argument --async -- which > probably sends the > script in the background -- otherwise the script cannot communicate with the > blocked NM. Yes. > It would be more robust, to call the script asynchronously because obviously > you don't need the synchrony behavior. I think it's better to keep the possibility to let the script perform some actions before giving control back to NetworkManager.
(In reply to comment #7) > (In reply to comment #6) > > It would be more robust, to call the script asynchronously because obviously > > you don't need the synchrony behavior. > > I think it's better to keep the possibility to let the script perform some > actions before giving control back to NetworkManager. Not sure, what actions could that be? Obviously the script cannot at all talk to NM (which is blocked). So, blocking it, has two possibly desirable effects: - the script is called only one-at-a-time, in the right order. - NM does not actively alter the state of the network, until the script returns Ok, I agree, this could be useful :)
Yeah, NM needs to call the plugins asynchronously, though that's hard at the various points that this happens. We'll need to work on this.
Thomas brought up a point on IRC that sync calls are fine, as long as the DNS plugin doesn't block for long periods of time in the code. So if the unbound plugin can (more or less) guarantee that the calls it makes do not block for more than 100ms or so, then we can make synchronous calls. If there are cases where we may wish to block for longer, like during connection activation when new DNS information is present, then we can *asynchronously* call the DNS plugins from the NMDevice activation stages (or VPN activation stages) and wait to transition state from eg IP_CHECK -> SECONDARIES or VPN_STATE_IP_CONFIG -> VPN_STATE_CONNECTED until the reply comes back. I'm already doing that for "pre-up" scripts in the dcbw/dispatcher-blocking branch, and the same strategy could be used for stuff like this.
(In reply to comment #10) > Thomas brought up a point on IRC that sync calls are fine, as long as the DNS > plugin doesn't block for long periods of time in the code. So if the unbound > plugin can (more or less) guarantee that the calls it makes do not block for > more than 100ms or so, then we can make synchronous calls. Thanks. The script only reads the command line forks and exits. Later it will probably need to check for a simultaneous run of the script. > If there are cases where we may wish to block for longer, like during > connection activation when new DNS information is present, then we can > *asynchronously* call the DNS plugins from the NMDevice activation stages In the long term, we will need to introduce asynchronicity to the DNS plugin API so that NetworkManager knows when the DNS is fully configured. > I'm already doing that for "pre-up" scripts in the > dcbw/dispatcher-blocking branch, and the same strategy could be used for stuff > like this. In the long term, all the actions will be bound to the main loop in the unbound plugin and no nontrivial external scripts will be called. Essentially the status will be moved from the script and on-disk files to the unbound plugin and its internal data. I will file separate bug(s) for the RFEs for the DNS plugin interface. The current status of the plugin calling an external script should be considered experimental.
Created attachment 277057 [details] [review] updated patch Updated patch with man page content improved.
Without this patch (i.e. the current state), dnssec-trigger will install itself as a dispatcher script, and being called appropriately. It already kind of works, right? I assume, that this (rudimentary) plugin still has advantages over the dispatcher solution, such as - being called in more appropriate situations(?) - being called only when NM.config has dns=unbound Could you detail the advantages and the reasoning in the commit message too? Then: - configuration with DNSSEC support. The /etc/resolv.conf - will be managed by dnssec-trigger daemon.</para> + configuration with DNSSEC support. /etc/resolv.conf + will be managed by dnssec-trigger daemon.</para> Regarding sync/async, I would prefer async, but probably that's more lines of code -- for something that is exprimental anyway and will be replaced soon. So, sync is fine for me. Rest looks good. I did not test it though.
(In reply to comment #13) > Without this patch (i.e. the current state), dnssec-trigger will install itself > as a dispatcher script, and being called appropriately. It already kind of > works, right? We are considering removing this feature so that dnssec-trigger doesn't disturb networkManager when not explicitly requested and later move dnssec-trigger functionality to the NetworkManager process itself. Right now dnssec-trigger sort of hijacks /etc/resolv.conf at startup.
Patch looks good to me too.
Pushed preliminary support to master. Keeping the bug report ASSIGNED for further updates. commit 186e4dcf7a0ebdd7432cf3e34d426b9d58bb85bc Author: Pavel Šimerda <psimerda@redhat.com> Date: Thu Apr 3 12:39:45 2014 +0200 dns: preliminary support for unbound (bgo #699810) The script is called synchronously from NetworkManager so it can handle asynchronicity itself. The long-term plan is to incorporate the script partially into the new plugin and partially into a dnssec-trigger library which will be used instead of dnssec-trigger daemon. https://bugzilla.gnome.org/show_bug.cgi?id=699810 Acked-By: Thomas Haller <thaller@redhat.com> Acked-By: Dan Williams <dcbw@redhat.com>
(In reply to comment #16) > Pushed preliminary support to master. Keeping the bug report ASSIGNED for > further updates. I propose to close this bug as RESOLVED/FIXED, and open new bugs for future features.
(In reply to comment #17) > (In reply to comment #16) > > Pushed preliminary support to master. Keeping the bug report ASSIGNED for > > further updates. > > I propose to close this bug as RESOLVED/FIXED, and open new bugs for future > features. I do not consider the feature described in this ticket complete just because we have pushed one commit to master. I would like to close this ticket when the feature is ready to use and only open bugs for new functionality. Removing from nm-review.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).