[Dnssec-trigger] [PATCH] NetworkManager hook should add unbound forward zones for VPN connections
Tomas Hozza
thozza at redhat.com
Thu Jul 4 07:22:47 UTC 2013
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
More information about the dnssec-trigger
mailing list