[Dnssec-trigger] [PATCH] Improved NM dispatcher hook script

[Tomas Hozza]

----- Original Message -----
> On Tue, 6 Aug 2013, Tomas Hozza wrote:
> 
> > In July I proposed a new modified NM dispatcher hook script.
> > I have been working on it and after discussion with Pavel
> > Simerda I came up with a new version of the script that
> > covers some corner cases. Hopefully it is also easier
> > to understand.
> 
> Thanks for the patch. I see two issues.
> 
> 1) Double work
> 
> if this patch is added, the existing openswan/libreswan and vpnc
> packages will add the domain forward twice, once via this new hook
> and once via their own mechanism. Currently, those setups work without
> needing dnssec-triggerd (eg just vpn software + unbound) but with this
> patch is now requires dnssec-triggerd running.

This is true, but I'm not sure how to solve this. Adding a check into 
dnssec-trigger script to check if there is libreswan/vpnc script does
not seems like the right solution to me. The same for adding a check into
libreswan/vpnc scripts if there is dnssec-trigger.

Anyway the information configured by VPN script(s) and dnssec-trigger
script should be the same and therefore should not do any harm. However
it is a doubling of work if you have both solutions configured.

> 2) Changing the default
> 
> This patch changes the default system resolver when the VPN comes up.
> This might not be desirable. When I bring up my redhat VPN, I only want
> to send the redhat.com DNS queries their way. With this patch, I will
> be sending _all_ DNS traffic their way.

The patch does not change the previous behaviour of the script regarding
the default system resolver.

The only change is that now it adds a forward zone to unbound if the connection
going up provided a domain and nameservers. So if the connection was VPN
and the list of default servers retrieved from NM using nmcli is different,
then nameservers provided by VPN will be used only for the domain that
was provides as well.

> With IPsec, we receive specifically the domain name(s) and DNS server
> IPs, as well as a list of routes that should go through the VPN (so
> called split tunnel). Other VPN implementations/configurations might send a
> request for 0.0.0.0/0 where it would be reasonable to expect that they
> want all traffic, and where they would want you to use their DNS.
> However, the notion of "use our DNS for some domains" versus "use our
> DNS for everything" is not negotiated for IPsec. Furthermore, again for
> our implementation, the VPN tunnel information is only available within
> our out software, and not exported/exposed to NM.

Since this was not done by the previous version of the dnssec-trigger script
there is no change in behaviour.

Regards,

Tomas