Bug 1067452

Summary:	connection zones lost when unbound is restarted
Product:	[Fedora] Fedora	Reporter:	Pavel Šimerda (pavlix) <psimerda>
Component:	dnssec-trigger	Assignee:	Pavel Šimerda (pavlix) <psimerda>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	pspacek, pwouters, thozza, vonsch
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	dnssec-trigger-0.12-13.fc20	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-09-19 10:06:51 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Pavel Šimerda (pavlix) 2014-02-20 13:34:13 UTC

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.

Comment 1 Pavel Šimerda (pavlix) 2014-02-20 13:47:58 UTC

Just to note, I will be happy to post it upstream when it's ready.

Comment 2 Paul Wouters 2014-02-20 16:49:44 UTC

sorry, what do you mean with a "connection zone"?

Comment 3 Tomáš Hozza 2014-02-21 07:30:40 UTC

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

Comment 4 Pavel Šimerda (pavlix) 2014-02-21 08:18:27 UTC

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.

Comment 5 Paul Wouters 2014-02-21 16:29:28 UTC

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?

Comment 6 Paul Wouters 2014-02-21 16:38:02 UTC

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.

Comment 7 Petr Spacek 2014-02-24 11:58:35 UTC

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

Comment 8 Tomáš Hozza 2014-02-24 12:15:25 UTC

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.

Comment 9 Pavel Šimerda (pavlix) 2014-03-19 10:47:37 UTC

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

Comment 10 Pavel Šimerda (pavlix) 2014-06-06 15:01:59 UTC

Fixed in 0.12, available in rawhide.

Comment 11 Pavel Šimerda (pavlix) 2014-06-06 17:13:55 UTC

I would like to track this for f20 instead.

Comment 12 Fedora Update System 2014-06-30 15:29:46 UTC

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

Comment 13 Fedora Update System 2014-07-01 07:21:24 UTC

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

Comment 14 Fedora Update System 2014-08-11 11:40:32 UTC

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

Comment 15 Fedora Update System 2014-09-19 10:06:51 UTC

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.