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

Tomas Hozza thozza at redhat.com
Fri Aug 9 18:14:03 UTC 2013


----- Original Message -----
> On 08/07/2013 10:00 AM, Tomas Hozza wrote:
> 
> > 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.
> 
> It's harmless only if it acts identical. But with 2) that's not the case
> in an important way.
> 
> 
> >> 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.
> 
> It seems to do as you say, which is confusing me a little. I see:
> 
> root at thinkpad:~# unbound-control list_forwards
> . IN forward: 192.168.2.100
> redhat.com. IN forward: 10.5.30.160 10.11.5.19
> 
> My DHCP gave me 192.168.2.100 and when I brought my VPN up using the
> unbound handling in libreswan, only the redhat.com. entry was added.
> 
> Your script runs this new section of code:
> 
> ############################################################
> # configure global nameservers using dnssec-trigger-control
> if [ -n "`pidof dnssec-triggerd`" ] ; then
>     dnssec-trigger-control submit "$global_nameservers" &> /dev/null
> 
> When I do that:
> 
> root at thinkpad:~#  dnssec-trigger-control submit 8.8.8.8
> root at thinkpad:~# unbound-control list_forwards
> . IN forward: 8.8.8.8
> redhat.com. IN forward: 10.5.30.160 10.11.5.19
> 
> This would happen with or without the vpn-up action being specified. But
> it seems to not get executed, as indeed my default forwarder is not changed.

The code you are mentioning is the same as in the original script. In fact I just
changed variables names and added a check if dnssed-triggerd is running. It had
to behave the same way before with the "old" script if you used it.

Regards,

Tomas



More information about the dnssec-trigger mailing list