dnssec-trigger NM dispatcher script doesn't ensure connection zones are configured when unbound is restarted. Steps to reproduce: 1) Check that you have at least one connection zone in unbound. 2) Restart unbound. 3) The connection zone is gone. Workaround: 1) rm -f /var/run/dnssec-trigger/* 2) Restart dnssec-trigger. Solution: First of all you need to change dnssec-triggerd.service unbound dependency from Wants to Requires to ensure that dnssec-triggerd.service can react on unbound.service. Second, you need to ensure dnssec-triggerd.service cleans up the directory so it's started afresh next time. Temporary patch: diff --git a/fedora/dnssec-triggerd.service b/fedora/dnssec-triggerd.service index 9d55778..14bdb0a 100644 --- a/fedora/dnssec-triggerd.service +++ b/fedora/dnssec-triggerd.service @@ -6,7 +6,7 @@ Wants=dnssec-triggerd-keygen.service After=dnssec-triggerd-resolvconf-handle.service Wants=dnssec-triggerd-resolvconf-handle.service After=unbound.service -Wants=unbound.service +Requires=unbound.service [Service] Type=simple @@ -16,6 +16,7 @@ ExecStart=/usr/sbin/dnssec-triggerd -d ExecStartPost=/etc/NetworkManager/dispatcher.d/01-dnssec-trigger-hook RestartSec=0 ExecStopPost=/usr/bin/chattr -i /etc/resolv.conf +ExecStopPost=rm -f /var/run/dnssec-trigger/* [Install] WantedBy=multi-user.target Unfortunately, this patch has a side effect. When only dnssec-triggerd is restarted, it could cause it to lose track of the settings already present in Unbound. I'm using it for my own testing, restarting Unbound as a workaround. The proper fix will be to remove the connection zones from Unbound before removing them from the disk. The most convenient way to do that is IMO to run the dispatcher script instead and let it cleanup whenever it sees dnssec-triggerd is not running. I think it would be best to also merge the resolv.conf handling script and the dispatcher script and the resulting script would be called from a trivial dispatcher script then. You would have all those cleanups and all those checks whether NM is running, whether dnssec-trigger is running, etc, in one place.
Just to note, I will be happy to post it upstream when it's ready.
sorry, what do you mean with a "connection zone"?
(In reply to Paul Wouters from comment #2) > sorry, what do you mean with a "connection zone"? I think Pavel means forward zones configured in unbound by the dnssec-trigger NM hook for connection provided domains (like VPN).
Confirmeding Tomáš's explanation, we're using it as a shortcut for 'forward zone provided by NetworkManager connection'. When we have Paul in the discussion, it would be good to note that Tomáš expressed his will in modifying the script so that the ExecStopPost workaround is not needed wich would make only the first part of the patch relevant.
When you dynamically reconfigure unbound, you obviously cannot just restart unbound and not lose information. I don't understand why this is considered a bug. I also don't see how dnssec-triggerd restart helps that? Lets say I start my redhat vpn. I get the XAUTH domain and DNS entries, and unbound is reconfigured with a forwarder for redhat.com. Restarting unbound causes that forwarding to be lost. Restarting dnssec-trigger does not bring that back. As the redhat.com entries come in over the vpn, the entries cannot be stored inside NM (they could, but then only for the life of the vpn tunnel), If we want to support a user randomly restarting unbound (why???) then the proper fix would be to store this information in NM as ephemeral, and on unbound startup signal NM for any ephemeral forwards that need to be re-added. But I don't see why we should support restarting the unbound server?
One could track the state of unbound too, eg during restart look at: unbound-control list_forwards and re-add those forwards after starting. However, to me that does not look like a "restart" as state from the previous run is kept and the restart might be meant to get rid of that configuration.
We should consider the case when unbound is restarted after package upgrade. You have ran 'dnf upgrade', new unbound was installed and (possibly) restarted. I wouldn't expect that this will break my connection to VPN ...
Thanks Peter for the valid use case example. (In reply to Paul Wouters from comment #6) > One could track the state of unbound too, eg during restart look at: > > unbound-control list_forwards > > and re-add those forwards after starting. However, to me that does not look > like a "restart" as state from the previous run is kept and the restart > might be meant to get rid of that configuration. I think we should automate this for the user if possible. And I think it should be possible. I doubt we want users to do all this stuff manually after somehow magically finding out that unbound was restarted by yum/dnf. (In reply to Paul Wouters from comment #5) > When you dynamically reconfigure unbound, you obviously cannot just restart > unbound and not lose information. I don't understand why this is considered > a bug. > > I also don't see how dnssec-triggerd restart helps that? > > Lets say I start my redhat vpn. I get the XAUTH domain and DNS entries, and > unbound is reconfigured with a forwarder for redhat.com. Restarting unbound > causes that forwarding to be lost. Restarting dnssec-trigger does not bring > that back. > > As the redhat.com entries come in over the vpn, the entries cannot be stored > inside NM (they could, but then only for the life of the vpn tunnel), I think the VPN software should "talk" to the NM so NM is aware of all system connections and is able to provide relevant data about them.
(In reply to Paul Wouters from comment #6) > One could track the state of unbound too, eg during restart look at: There's no actual need to track the state of unbound, as the NetworkManager connection provided zones can be queried at any time. My solution is to have dnssec-triggerd restarted upon unbound restart (by systemd dependency) and let the script handle the situation and reinstall the connection zones to unbound. I'm going to post the new script upstream ASAP. (In reply to Paul Wouters from comment #5) > I also don't see how dnssec-triggerd restart helps that? The restart of dnssec-triggerd.service results in running the script that then reinstalls the connection zones to unbound. > Lets say I start my redhat vpn. I get the XAUTH domain and DNS entries, and > unbound is reconfigured with a forwarder for redhat.com. Restarting unbound > causes that forwarding to be lost. Restarting dnssec-trigger does not bring > that back. The script works for VPNs managed by networkmanager. But it's just a script, it could be amended to use other sources as well if someone wants to improve it for non-networkmanager use cases. > As the redhat.com entries come in over the vpn, the entries cannot be stored > inside NM (they could, but then only for the life of the vpn tunnel) I'm using networkmanager OpenVPN plugin and it works as expected, whether unbound, dnsmasq or none of them is used. > If we want to support a user randomly restarting unbound (why???) Use case 1 (described already): RPM restarts a service on (security) update. Use case 2: Administrator starts/stops using dnssec-trigger and unbound. This is technically not a restart, but it works almost the same way. Use case 3: Administrator changes configuration of unbound and restarts it. Use case 4: Administrator touches /etc/resolv.conf directly or changes unbound via unbound-control and wants to get back to a fresh state. I'm going to sent the new script upstream ASAP.
Fixed in 0.12, available in rawhide.
I would like to track this for f20 instead.
dnssec-trigger-0.12-12.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/dnssec-trigger-0.12-12.fc20
Package dnssec-trigger-0.12-12.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnssec-trigger-0.12-12.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7942/dnssec-trigger-0.12-12.fc20 then log in and leave karma (feedback).
dnssec-trigger-0.12-13.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/dnssec-trigger-0.12-13.fc20
dnssec-trigger-0.12-13.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.