From thozza at redhat.com Tue Aug 6 13:42:33 2013 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 6 Aug 2013 09:42:33 -0400 (EDT) Subject: [Dnssec-trigger] [PATCH] Improved NM dispatcher hook script In-Reply-To: <1406278138.6127923.1375795456788.JavaMail.root@redhat.com> Message-ID: <689751090.6135352.1375796553611.JavaMail.root@redhat.com> Hello. 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. Corner cases that I'm speaking of are particularly those when you connect to a VPN or any network that provides you with a nameservers and a domain, but those nameservers have broken DNSSEC configuration. In this case you would be possibly unable to resolve domain names from the provided domain, if only those provided nameservers can resolve them. The reason is that dnssec-trigger would ignore those nameservers because of the broken DNSSEC configuration. In this particular situation I think the user would like to be able to resolve those internal domain names using provided nameservers even though the DNSSEC is broken. But only domain names from the provided domain. For the rest, nameservers chosen by dnssec-trigger based on its configuration should be used. Described corner cases can be solved by adding a insecure forward zone into unbound. Unfortunately dnssec-trigger-control does not provides an interface to do this, therefore I used unbound-control directly. There is also a possibility by changing single script variable to change the behaviour of the script so it adds secure instead of insecure forward zones. I'm attaching the patch for the latest trunk version and also the NM script itself because it is more readable than from patch. Regards, Tomas Hozza -------------- next part -------------- A non-text attachment was scrubbed... Name: 01-dnssec-trigger-hook.sh.in Type: application/octet-stream Size: 3441 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Improve-NM-dispatcher-hook-script.patch Type: text/x-patch Size: 5760 bytes Desc: not available URL: From wouter at nlnetlabs.nl Tue Aug 6 14:53:17 2013 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Tue, 06 Aug 2013 16:53:17 +0200 Subject: [Dnssec-trigger] [PATCH] Improved NM dispatcher hook script In-Reply-To: <689751090.6135352.1375796553611.JavaMail.root@redhat.com> References: <689751090.6135352.1375796553611.JavaMail.root@redhat.com> Message-ID: <52010DDD.1080002@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tomas, Committed, I changed this bit: # Remove forward zone from unbound if [ "$validate_forward_zones" == "no" ]; then unbound-control forward_remove +i $domain &> /dev/null else unbound-control forward_remove $domain &> /dev/null fi The forward_remove also needs the +i flag to remove the insecure point that was created by the forward_add +i. Thank you for the patch! VPN support is very nice to have. Best regards, Wouter On 08/06/2013 03:42 PM, Tomas Hozza wrote: > Hello. > > 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. > > Corner cases that I'm speaking of are particularly those when you > connect to a VPN or any network that provides you with a > nameservers and a domain, but those nameservers have broken DNSSEC > configuration. In this case you would be possibly unable to resolve > domain names from the provided domain, if only those provided > nameservers can resolve them. The reason is that dnssec-trigger > would ignore those nameservers because of the broken DNSSEC > configuration. In this particular situation I think the user would > like to be able to resolve those internal domain names using > provided nameservers even though the DNSSEC is broken. But only > domain names from the provided domain. For the rest, nameservers > chosen by dnssec-trigger based on its configuration should be > used. > > Described corner cases can be solved by adding a insecure forward > zone into unbound. Unfortunately dnssec-trigger-control does not > provides an interface to do this, therefore I used unbound-control > directly. There is also a possibility by changing single script > variable to change the behaviour of the script so it adds secure > instead of insecure forward zones. > > I'm attaching the patch for the latest trunk version and also the > NM script itself because it is more readable than from patch. > > Regards, > > Tomas Hozza > > > > _______________________________________________ dnssec-trigger > mailing list dnssec-trigger at NLnetLabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSAQ3dAAoJEJ9vHC1+BF+NhnIP/2301lp6saB3knSDphqwVykZ jGpnYAcbniqj/8lGcgYUMxEjdUCFWyzBhXBs0gX+3JrJa/lqZ1X1o2hupizljwjp 3L1IYdnnDE78jp92qnWaepRT4pfxPKkDmVaDq5QXxL67d8QxJWM3Fo+ip+y/MsN8 hKSjjQkQZkRXRg5H44sC9+WtBo1bwaQjAemtHvuK8ftu9VW0KyoDggkXIxEIbGN3 ltKK82D84E8dYfjlwxugstZYpNpM0ALojLAjoAU6gogYRVAprFDM8XzF/cDUy1Vc GROa2/L+ijtUlQPaZj2gvfySxTt1RefHH9y9KFPTMutcC0WMYa/OEhb6rANNK5E5 4WkphzU6/VxfNrv+UNglJ78RPY0x+ojJ2+VtkCWOxpjvHafQ8HmTzvNjHvcTg6b/ NziGS9WAZzOKqweJlgxsnQRxEKOAVgZSaWpNX09B8+unzvTagBaUxXS0fRgbNvSF tbRamNMkjI6zUw7CF0aV6j44m8YOFrQwjeCKrwmrZ62pRgZzhjhfEW3GYjUzPp+v kcJbLcIlNqFl+pJHlWuzD5S9tkEPjXut4rtnwfoBzHKvGHvvUZNsBpuW20UisAsJ 4naiNlted9DTy38VzBRbq1BRcM93tm2ZeAKM81GdMSs+b8MULKdkreXlqPPbAjMk mNPHOfU4oZglWW+AC/fv =HUOt -----END PGP SIGNATURE----- From pwouters at redhat.com Tue Aug 6 17:28:20 2013 From: pwouters at redhat.com (Paul Wouters) Date: Tue, 6 Aug 2013 13:28:20 -0400 (EDT) Subject: [Dnssec-trigger] [PATCH] Improved NM dispatcher hook script In-Reply-To: <689751090.6135352.1375796553611.JavaMail.root@redhat.com> References: <689751090.6135352.1375796553611.JavaMail.root@redhat.com> Message-ID: 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. 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. 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. I am not sure how best to fix these two problems. While 1) is fairly benign, 2) is very important. Paul From thozza at redhat.com Wed Aug 7 08:00:23 2013 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 7 Aug 2013 04:00:23 -0400 (EDT) Subject: [Dnssec-trigger] [PATCH] Improved NM dispatcher hook script In-Reply-To: References: <689751090.6135352.1375796553611.JavaMail.root@redhat.com> Message-ID: <1283515975.6384982.1375862423136.JavaMail.root@redhat.com> ----- 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 From pwouters at redhat.com Fri Aug 9 14:24:56 2013 From: pwouters at redhat.com (Paul Wouters) Date: Fri, 09 Aug 2013 10:24:56 -0400 Subject: [Dnssec-trigger] [PATCH] Improved NM dispatcher hook script In-Reply-To: <1283515975.6384982.1375862423136.JavaMail.root@redhat.com> References: <689751090.6135352.1375796553611.JavaMail.root@redhat.com> <1283515975.6384982.1375862423136.JavaMail.root@redhat.com> Message-ID: <5204FBB8.2080400@redhat.com> 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. Paul From thozza at redhat.com Fri Aug 9 18:14:03 2013 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 9 Aug 2013 14:14:03 -0400 (EDT) Subject: [Dnssec-trigger] [PATCH] Improved NM dispatcher hook script In-Reply-To: <5204FBB8.2080400@redhat.com> References: <689751090.6135352.1375796553611.JavaMail.root@redhat.com> <1283515975.6384982.1375862423136.JavaMail.root@redhat.com> <5204FBB8.2080400@redhat.com> Message-ID: <220773499.7214764.1376072043583.JavaMail.root@redhat.com> ----- 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