From thozza at redhat.com Tue Jul 2 13:16:07 2013 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 2 Jul 2013 09:16:07 -0400 (EDT) Subject: [Dnssec-trigger] [PATCH] NetworkManager hook should add unbound forward zones for VPN connections In-Reply-To: <1842926104.13358341.1372671542154.JavaMail.root@redhat.com> Message-ID: <1140009112.13746115.1372770967599.JavaMail.root@redhat.com> Hello. As you maybe know, in Fedora we have DNSSEC on workstations feature since Fedora 18. It used unbound and dnssec-trigger to take care of DNSSEC validation and resolv.conf configuration. I know there is much more that dnssec-trigger does in addition (detect Hotspot, etc.). Recently I discovered that dnssec-trigger works really good until you try to use it with a VPN to some corporate network, which provides its own DNS servers together with internal domain(s). Currently dnssec-trigger provides a NM dispatcher script that adds DHCP obtained DNS servers into dnssec-triggerd. But when it comes to VPN connections, dnssec-trigger relies completely on VPN clients to configure unbound and add forwarding zones if obtained from VPN. This causes dnssec-trigger together with unbound not to work out of the box when used with VPNs (which is really common use case). I think the dispatcher script should be modified to handle also VPN provided domains and configure unbound if needed, rather than rely on third parties scripts to do it. I know there are some issues in NM and dispatcher preventing this to be done. BUT one needed change to NetworkManager have been already merged into upstream [1] and one more [2] is still pending, but I expect it to get into upstream, too. If not, I'm ready to solve this issue other way. I'm sending you also my proposed changes to the dispatcher script. It is based on script version in repository trunk. It also expects both NM proposed changes [1, 2] to be merged into NM upstream. Thank you. Regards, Tomas Hozza [1] https://bugzilla.gnome.org/show_bug.cgi?id=701820 [2] https://bugzilla.gnome.org/show_bug.cgi?id=703395 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-NM-hook-configure-unbound-in-case-of-vpn-up-down.patch Type: text/x-patch Size: 4016 bytes Desc: not available URL: From pwouters at redhat.com Wed Jul 3 19:26:10 2013 From: pwouters at redhat.com (Paul Wouters) Date: Wed, 3 Jul 2013 15:26:10 -0400 (EDT) Subject: [Dnssec-trigger] [PATCH] NetworkManager hook should add unbound forward zones for VPN connections In-Reply-To: <1140009112.13746115.1372770967599.JavaMail.root@redhat.com> References: <1140009112.13746115.1372770967599.JavaMail.root@redhat.com> Message-ID: On Tue, 2 Jul 2013, Tomas Hozza wrote: > Recently I discovered that dnssec-trigger works really good until you > try to use it with a VPN to some corporate network, which provides > its own DNS servers together with internal domain(s). Note, I said before this is a really personally coloured view by you. There is various support in openswan, libreswan and vpnc that works really well. Sure, openvpn is missing, but it can launch any custom shell script on the client, so it should not be hard to just push the unbound-control commands down the client. > Currently dnssec-trigger provides a NM dispatcher script that adds > DHCP obtained DNS servers into dnssec-triggerd. But when it comes > to VPN connections, dnssec-trigger relies completely on VPN clients > to configure unbound and add forwarding zones if obtained from VPN. > This causes dnssec-trigger together with unbound not to work out of > the box when used with VPNs (which is really common use case). You mean _some_ VPN clients. > I think the dispatcher script should be modified to handle also VPN > provided domains and configure unbound if needed, rather than rely on > third parties scripts to do it. I know there are some issues in NM > and dispatcher preventing this to be done. > > BUT one needed change to NetworkManager have been already merged into > upstream [1] and one more [2] is still pending, but I expect it to > get into upstream, too. If not, I'm ready to solve this issue other way. > > I'm sending you also my proposed changes to the dispatcher script. It > is based on script version in repository trunk. It also expects both > NM proposed changes [1, 2] to be merged into NM upstream. I have no principle problems with the patch. And I agree it would be best that all parties talk to NM as the central point, and only NM runs unbound-control and changes /etc/resolv.conf. If the NM and dnssec-trigger patches are upstream, I'm willing to change the libreswan/openswan/vpnc scripts to call NM instead of doing the work themselves. But please stop saying dnssec-trigger does not work with VPNs. Paul From thozza at redhat.com Thu Jul 4 07:22:47 2013 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 4 Jul 2013 03:22:47 -0400 (EDT) Subject: [Dnssec-trigger] [PATCH] NetworkManager hook should add unbound forward zones for VPN connections In-Reply-To: References: <1140009112.13746115.1372770967599.JavaMail.root@redhat.com> Message-ID: <425693798.14302214.1372922567485.JavaMail.root@redhat.com> First of all, thank you for your response and feedback. ----- Original Message ----- > On Tue, 2 Jul 2013, Tomas Hozza wrote: > > > Recently I discovered that dnssec-trigger works really good until you > > try to use it with a VPN to some corporate network, which provides > > its own DNS servers together with internal domain(s). > > Note, I said before this is a really personally coloured view by you. > There is various support in openswan, libreswan and vpnc that works > really well. Sure, openvpn is missing, but it can launch any custom > shell script on the client, so it should not be hard to just push > the unbound-control commands down the client. I'm sorry if it sounded like dnssec-trigger does not work with VPNs at all. I don't want to say that, because it is not true. What I'm saying is, that from my experience it does not work out of the box without further configuration (I tried vpnc and openvpn). > > Currently dnssec-trigger provides a NM dispatcher script that adds > > DHCP obtained DNS servers into dnssec-triggerd. But when it comes > > to VPN connections, dnssec-trigger relies completely on VPN clients > > to configure unbound and add forwarding zones if obtained from VPN. > > This causes dnssec-trigger together with unbound not to work out of > > the box when used with VPNs (which is really common use case). > > You mean _some_ VPN clients. That is true. I tested only vpnc and openvpn and should be more specific. I should also say that there is a pending patch from YOU for vpnc that adds the support for configuring unbound. But AFAIK it requires extra configuration to work. > > I think the dispatcher script should be modified to handle also VPN > > provided domains and configure unbound if needed, rather than rely on > > third parties scripts to do it. I know there are some issues in NM > > and dispatcher preventing this to be done. > > > > BUT one needed change to NetworkManager have been already merged into > > upstream [1] and one more [2] is still pending, but I expect it to > > get into upstream, too. If not, I'm ready to solve this issue other way. > > > > I'm sending you also my proposed changes to the dispatcher script. It > > is based on script version in repository trunk. It also expects both > > NM proposed changes [1, 2] to be merged into NM upstream. > > I have no principle problems with the patch. And I agree it would be > best that all parties talk to NM as the central point, and only > NM runs unbound-control and changes /etc/resolv.conf. That is exactly what is my intention. I think that there should be a single point where unbound is configured. In current circumstances I think, the NM dispatcher script is the best place for this functionality. Another advantage is that we won't have to change script in each VPN client if needed, but only in one place. > If the NM and dnssec-trigger patches are upstream, I'm willing to > change the libreswan/openswan/vpnc scripts to call NM instead of > doing the work themselves. > > But please stop saying dnssec-trigger does not work with VPNs. I'll be more specific next time. Thank you. Regards, Tomas Hozza From pwouters at redhat.com Fri Jul 5 00:09:52 2013 From: pwouters at redhat.com (Paul Wouters) Date: Thu, 4 Jul 2013 20:09:52 -0400 (EDT) Subject: [Dnssec-trigger] [PATCH] NetworkManager hook should add unbound forward zones for VPN connections In-Reply-To: <425693798.14302214.1372922567485.JavaMail.root@redhat.com> References: <1140009112.13746115.1372770967599.JavaMail.root@redhat.com> <425693798.14302214.1372922567485.JavaMail.root@redhat.com> Message-ID: On Thu, 4 Jul 2013, Tomas Hozza wrote: > That is true. I tested only vpnc and openvpn and should be more specific. > I should also say that there is a pending patch from YOU for vpnc that > adds the support for configuring unbound. But AFAIK it requires extra > configuration to work. That should not be the case since IPsec with XAUTH sends the DNS domain and the list of nameservers. The patched vpnc just called unbound-control like openswan/libreswan does. >> I have no principle problems with the patch. And I agree it would be >> best that all parties talk to NM as the central point, and only >> NM runs unbound-control and changes /etc/resolv.conf. > > That is exactly what is my intention. I think that there should be > a single point where unbound is configured. In current circumstances I think, > the NM dispatcher script is the best place for this functionality. Another > advantage is that we won't have to change script in each VPN client > if needed, but only in one place. VPN programs still need to be changed to use NM scripts, and when NM is not there, perform the action themselves. Unless dnssec-triggerd is modified to do all that, and the VPN programs just use some new option to tell dnssec-triggerd. But I am not sure if non-IPsec VPNs have some standard way of relaying this information. I think the most ideal situation is if NM takes over part of dnssec-triggerd as a plugin, so we don't need to run another daemon. But for that, NM needs to also integrate hot spot detection and all. Paul From psimerda at redhat.com Mon Jul 8 10:01:28 2013 From: psimerda at redhat.com (Pavel Simerda) Date: Mon, 8 Jul 2013 06:01:28 -0400 (EDT) Subject: [Dnssec-trigger] [PATCH] NetworkManager hook should add unbound forward zones for VPN connections In-Reply-To: References: <1140009112.13746115.1372770967599.JavaMail.root@redhat.com> <425693798.14302214.1372922567485.JavaMail.root@redhat.com> Message-ID: <266162396.137045.1373277688814.JavaMail.root@redhat.com> > From: "Paul Wouters" > I think the most ideal situation is if NM takes over part of > dnssec-triggerd as a plugin, so we don't need to run another daemon. We talked about it a while ago and it sounds like a good idea. But I don't think running or not running another deamon is important. I would rather focus on what we can do, what we can gain and how much time we need to invest. > for that, NM needs to also integrate hot spot detection and all. That would be a plausible side effect, as NM would use hotspot detection for other stuff, too. Pavel