From thozza at redhat.com Tue Jan 21 15:33:21 2014 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 21 Jan 2014 10:33:21 -0500 (EST) Subject: [Dnssec-trigger] New dnssec-trigger NM dispatcher script In-Reply-To: <97562003.2309809.1390293023537.JavaMail.root@redhat.com> Message-ID: <83642376.2585231.1390318401718.JavaMail.root@redhat.com> Hello. For last couple of days I've been working on new dnssec-trigger dispatcher script due to some issues in the current one that are hard to overcome in the current script. The main reasons were: The script relies only on information provided via Environment variables set by NM when dispatcher runs the script. This results in some unwanted situations: 1. Imagine you boot up the system. NM is started before dnssec-trigger and unbound, therefore all informations about domains provided by existing connections are discarded. So if you were already at the boot time connected to a network that provides domains via DHCP no forward zones were added for such domains into the unbound. Till now there was no possible way how one could get those information from NM during the runtime, especially for VPN, but this is already fixed in the latest NM git snapshot. 2. Imagine you have two connections that provide the same domain. One is VPN and one is not. In current situation the last connected connection and by it provided NS would be used for that domain. By my opinion and by what I discussed with Pavel Simerda it makes more sense for the VPN to be preferred. 3. Imagine you have two connections that provide the same domain. One is VPN and one is not. Forward zone for provided domain has been added into unbound by the dispatcher script. If you then disconnect the connection for which the forward zone has been configured, it is removed by the dispatcher script. However even there is another connection providing the same domain the forward zone is not added, because it is added only if the connection goes UP. Due to these reasons I rewrote the script into Python and used the NM libnm-glib Python bindings that allow one to get information for current active connections from NM. However for NM to support everything correctly you need to use the latest 0.9.9.0 git snapshot. Necessary patches are backported in Fedora 20+. There is still one issue with getting IPv6 addresses of nameservers, but Jiri Klimes (NetworkManager developer) is already looking into it so I expect a fix soon. I used python, since the logic is more complicated and also it was beneficial to use OOP in this case. The new script works as follows: A. It gets all active connections from NM that have provided some NS. It gets information if the connection is VPN, or is marked as default connection by NM (for IPv4 or IPv6). B. Global forwarder are configured using dnssec-trigger-control. 1. Only active connections marked by NM as default (4 or 6) are filtered. 2. NSs provided by such connections are combined into one list (both IPv4 and IPv6 addresses) and passed to dnssec-trigger-control. C. Forward zones for domains provided by active connections are configured using unbound-control 1. Only active connections with domains provided are filtered. 2. Dictionary for "domain" -> is constructed, so it is clear which NS should be used for the particular domain (forward zone). - If there are two connections that provide the same domain and one of them is VPN, the VPN connection is preferred. - If there are two connections that provide the same domain and none of them are VPNs or both are VPNs and one of them is marked by NM as default (for IPv4 or IPv6). - As it is unclear what should be done if there are two connections providing the same domain and none of them is VPN or both are VPNs, one of the connections is used (without specific preference). Once there is some consensus on what should be done in such situation the logic can be adjusted without problems. 3. Previously configured Forward zones for non existing connections are removed from unbound. 4. Previously configured Forward zones for connections which UUID is different than the UUID of connection that should be used for the domain are removed from unbound. - example: you are connected via wire to network that provides "example.com" domain therefore it has been configured as forward into unbound. But after that you are connecting to a VPN that provides also "exmaple.com" domain, so the VPN provided NS should be used and previously configured zone needs to be removed first. 5. Still configured forward zones in unbound are removed from the dictionary of zones that need to be added to unbound. - This needs to be done to ensure that forward zones configured manually in unbound.conf are not replaced by dynamic ones. 6. Forward zones from dictionary are configured into unbound. I also extracted the option for whether to configure secured or unsecured forward zones to /etc/dnssec.conf file. This was done so the option can be reused also by other tools, not only dnssec-trigger, as we (me and Pavel Simerda) plan to implement equivalent functionality and unbound plugin for NetworkManager. The configuration file does not need to exist, the default behaviour is also specified in the script itself. The option name is "validate_connection_provided_zones" since from our point of view it is more self-explanatory than "forward zones" used unbound terminology. Due to the very latest NM version needed for this script to work I would not recommend it to replace the current shell script. It would be enough to include it in a contrib/ subdir. Even tough I would like to hear some feedback on it. Thank you in advance. Regards, Tomas Hozza -------------- next part -------------- A non-text attachment was scrubbed... Name: 01-dnssec-trigger-hook-new_nm Type: text/x-python Size: 16046 bytes Desc: not available URL: From wouter at nlnetlabs.nl Tue Jan 21 16:47:09 2014 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Tue, 21 Jan 2014 17:47:09 +0100 Subject: [Dnssec-trigger] New dnssec-trigger NM dispatcher script In-Reply-To: <83642376.2585231.1390318401718.JavaMail.root@redhat.com> References: <83642376.2585231.1390318401718.JavaMail.root@redhat.com> Message-ID: <52DEA48D.2080700@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tomas, On 01/21/2014 04:33 PM, Tomas Hozza wrote: > Hello. > > For last couple of days I've been working on new dnssec-trigger > dispatcher script due to some issues in the current one that are > hard to overcome in the current script. Thank you for the contribution. Yes the python and NM -git version dependency makes it hard to include it by default in the source; if NM was released I could version-check for python and NM- in configure.ac and include it conditionally. Best regards, Wouter > The main reasons were: The script relies only on information > provided via Environment variables set by NM when dispatcher runs > the script. This results in some unwanted situations: > > > 1. Imagine you boot up the system. NM is started before > dnssec-trigger and unbound, therefore all informations about > domains provided by existing connections are discarded. > > So if you were already at the boot time connected to a network > that provides domains via DHCP no forward zones were added for such > domains into the unbound. > > Till now there was no possible way how one could get those > information from NM during the runtime, especially for VPN, but > this is already fixed in the latest NM git snapshot. > > > 2. Imagine you have two connections that provide the same domain. > One is VPN and one is not. In current situation the last connected > connection and by it provided NS would be used for that domain. By > my opinion and by what I discussed with Pavel Simerda it makes more > sense for the VPN to be preferred. > > > 3. Imagine you have two connections that provide the same domain. > One is VPN and one is not. Forward zone for provided domain has > been added into unbound by the dispatcher script. If you then > disconnect the connection for which the forward zone has been > configured, it is removed by the dispatcher script. However even > there is another connection providing the same domain the forward > zone is not added, because it is added only if the connection goes > UP. > > > Due to these reasons I rewrote the script into Python and used the > NM libnm-glib Python bindings that allow one to get information for > current active connections from NM. However for NM to support > everything correctly you need to use the latest 0.9.9.0 git > snapshot. Necessary patches are backported in Fedora 20+. There is > still one issue with getting IPv6 addresses of nameservers, but > Jiri Klimes (NetworkManager developer) is already looking into it > so I expect a fix soon. I used python, since the logic is more > complicated and also it was beneficial to use OOP in this case. > > The new script works as follows: > > A. It gets all active connections from NM that have provided some > NS. It gets information if the connection is VPN, or is marked as > default connection by NM (for IPv4 or IPv6). > > B. Global forwarder are configured using dnssec-trigger-control. 1. > Only active connections marked by NM as default (4 or 6) are > filtered. 2. NSs provided by such connections are combined into one > list (both IPv4 and IPv6 addresses) and passed to > dnssec-trigger-control. > > C. Forward zones for domains provided by active connections are > configured using unbound-control 1. Only active connections with > domains provided are filtered. 2. Dictionary for "domain" -> is > constructed, so it is clear which NS should be used for the > particular domain (forward zone). - If there are two connections > that provide the same domain and one of them is VPN, the VPN > connection is preferred. - If there are two connections that > provide the same domain and none of them are VPNs or both are VPNs > and one of them is marked by NM as default (for IPv4 or IPv6). - As > it is unclear what should be done if there are two connections > providing the same domain and none of them is VPN or both are > VPNs, one of the connections is used (without specific preference). > Once there is some consensus on what should be done in such > situation the logic can be adjusted without problems. 3. Previously > configured Forward zones for non existing connections are removed > from unbound. 4. Previously configured Forward zones for > connections which UUID is different than the UUID of connection > that should be used for the domain are removed from unbound. - > example: you are connected via wire to network that provides > "example.com" domain therefore it has been configured as forward > into unbound. But after that you are connecting to a VPN that > provides also "exmaple.com" domain, so the VPN provided NS should > be used and previously configured zone needs to be removed first. > 5. Still configured forward zones in unbound are removed from the > dictionary of zones that need to be added to unbound. - This needs > to be done to ensure that forward zones configured manually in > unbound.conf are not replaced by dynamic ones. 6. Forward zones > from dictionary are configured into unbound. > > > I also extracted the option for whether to configure secured or > unsecured forward zones to /etc/dnssec.conf file. This was done so > the option can be reused also by other tools, not only > dnssec-trigger, as we (me and Pavel Simerda) plan to implement > equivalent functionality and unbound plugin for NetworkManager. The > configuration file does not need to exist, the default behaviour is > also specified in the script itself. The option name is > "validate_connection_provided_zones" since from our point of view > it is more self-explanatory than "forward zones" used unbound > terminology. > > > Due to the very latest NM version needed for this script to work I > would not recommend it to replace the current shell script. It > would be enough to include it in a contrib/ subdir. > > > Even tough I would like to hear some feedback on it. > > Thank you in advance. > > 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS3qSNAAoJEJ9vHC1+BF+NrucP/0Tp7/xCvn+BWAP+g6aa52ZD g6gH2PvO7GZpRTpVIxW/PrHbXvsTCzECB+H9+lO7TIga93IBHSzqo59VpApQzTWE cLr6psX3FS2bN4Qn9owqPou4nC1qANM44BU+dDKsfGnfTEcir+Y8nvEESGO04br9 B38W4k9F3i8VdhdoZSTzVGyXaWsoDPuNbuRTnwu8qC2M5z0tbWJd7ItIv6YM8aih M/FBJHe1V11+Twxf5ePvzmOxkmrUOGS9AOIq7CgysCy4pm/q/8IHcr+jXgHBia9n jV482sNwooggFUb893TEXnarUvkbXeGAO/oNbxLAL7OikphCC/y0JmnrL/PgNM8a 8mdYFt2MO38E97byiC1PVwcmGr5GwwDpQImux/wkPNTkRy0rOzx0LcwHoRc1g2D4 XsdKNMDehRTWGZoNPjucPVh2pPauJzTggQJsvX6I10VmtOcGyGqBMH9Ewi/aGb28 j6v5SkNoiNOu7giziLH11116NCkaNmufmHFnW7Lq84EP0dQhoIK4CZsMp33aj4JB wBXqdlwdYVcZ1O3GjAj9b5BMc9h9aMKlazrcasyt9+lAbWKCaS7fJnfADRSSJXUO 3zht6AYs/if8dRLd9RJQnu/6g3NI/trptn3ffoh6fmLVSCaN4NdTen5o0bSkDitV 7qaXV2IIexB9hesg03VS =upXr -----END PGP SIGNATURE----- From paul at nohats.ca Tue Jan 21 21:36:43 2014 From: paul at nohats.ca (Paul Wouters) Date: Tue, 21 Jan 2014 16:36:43 -0500 (EST) Subject: [Dnssec-trigger] New dnssec-trigger NM dispatcher script In-Reply-To: <83642376.2585231.1390318401718.JavaMail.root@redhat.com> References: <83642376.2585231.1390318401718.JavaMail.root@redhat.com> Message-ID: On Tue, 21 Jan 2014, Tomas Hozza wrote: > > 1. Imagine you boot up the system. NM is started before dnssec-trigger > and unbound, therefore all informations about domains provided by > existing connections are discarded. What information is provided and disgarded? You mean NM tries to configure a domani forward and since no unbound is running the add_forward is lost? If so, why are we not starting unbound DNS before NM? > So if you were already at the boot time connected to a network that > provides domains via DHCP no forward zones were added for such domains > into the unbound. I was not aware we are unconditionally forwarding random DHCP domains to random resolvers. You mean if I create a wifi network with search domain redhat.com and the IP of my nameserver, you are going to redirect all my DNS lookups? That would be a security problem. While dhcp domains from static LAN networks can usually be trusted, I don't want to trust dhcp domains from random wifi access points. And the only possibly use for that I see is to get past the hotspot/login page, which I believe should have its own web page and DNS handling anyway. > Till now there was no possible way how one could get those information > from NM during the runtime, especially for VPN, but this is already > fixed in the latest NM git snapshot. I don't understand how your VPN can be up before your local DNS server is up? One would assume you need a DNS server to reach the VPN server? > 2. Imagine you have two connections that provide the same domain. > One is VPN and one is not. In current situation the last connected > connection and by it provided NS would be used for that domain. That is wrong. Luckilly, currently at least the IPsec VPN duplicates this DNS effort and will overwrite the NM behaviour. > By my opinion and by what I discussed with Pavel Simerda it makes > more sense for the VPN to be preferred. More strongly, why did NM accept that first domain to begin with? > 3. Imagine you have two connections that provide the same domain. > One is VPN and one is not. Forward zone for provided domain has > been added into unbound by the dispatcher script. If you then > disconnect the connection for which the forward zone has been > configured, it is removed by the dispatcher script. However even > there is another connection providing the same domain the > forward zone is not added, because it is added only if the connection > goes UP. That I can see as a problem only when we are on a "secure" LAN that provided the dns forwards. It should never apply to wifi. And for that, NM has all the information when it is notified that the VPN goes down, to redo the DNS forward. > Due to these reasons I rewrote the script into Python and used > the NM libnm-glib Python bindings that allow one to get information > for current active connections from NM. Great! Having a better NM intergration is awesome! > The new script works as follows: > > A. It gets all active connections from NM that have provided > some NS. What does this mean? A NM manual configuration? Or a combination of receiving domain and DNS servers from DHCP? > It gets information if the connection is VPN, > or is marked as default connection by NM (for IPv4 or IPv6). > > B. Global forwarder are configured using dnssec-trigger-control. > 1. Only active connections marked by NM as default (4 or 6) > are filtered. I'm not sure what this means? Is a connection "eth0"? Or "StarBucks wifi" ? What makes a 'connection' a 'default' ? > 2. NSs provided by such connections are combined into one list > (both IPv4 and IPv6 addresses) and passed to dnssec-trigger-control. > > C. Forward zones for domains provided by active connections are configured > using unbound-control > 1. Only active connections with domains provided are filtered. What is a "filter" in terms of "connection"? domain names received from DHCP? Does dnssec-triggerd still have a "sane" state when you reconfigure unbound manually outside dnssec-triggerd? I assume those unbound-control calls are never for the global DNS resolving, but only specific domains? Like when my DHCP server returns my nameserver and a domains ".", I assume you will not send an unbound_control forward_add for "." ? > 4. Previously configured Forward zones for connections which UUID > is different than the UUID of connection that should be used > for the domain are removed from unbound. > - example: you are connected via wire to network that provides > "example.com" domain therefore it has been configured as forward > into unbound. As I said, I think this is dangerous. I don't want random networks to start giving me DNS server redirects for "google.com" or other things. While I'm willing to say that for a wire you can do this, I don't really want this behaviour per default for wifi. I don't really control what wifis my laptop connects to. > I also extracted the option for whether to configure secured or unsecured > forward zones to /etc/dnssec.conf file. This was done so the option > can be reused also by other tools, not only dnssec-trigger, as we (me and > Pavel Simerda) plan to implement equivalent functionality and unbound > plugin for NetworkManager. The configuration file does not need > to exist, the default behaviour is also specified in the script itself. > The option name is "validate_connection_provided_zones" since from our > point of view it is more self-explanatory than "forward zones" used unbound > terminology. I'd be happier if this would become an option one can set in the network properties of NM, "allow network to forward 'redhat.com' to its supplied nameservers", with a default of off, and possible a prompting for LANs and and no prompting for wifi, with the only wifi option to manually go into the network properties. I am not sure I see the value of doing this seperately from NM in a new config file. Paul From thozza at redhat.com Wed Jan 22 09:47:59 2014 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 22 Jan 2014 04:47:59 -0500 (EST) Subject: [Dnssec-trigger] New dnssec-trigger NM dispatcher script In-Reply-To: References: <83642376.2585231.1390318401718.JavaMail.root@redhat.com> Message-ID: <173547297.2792734.1390384079820.JavaMail.root@redhat.com> Hi Paul. Thank you for your feedback. ----- Original Message ----- > On Tue, 21 Jan 2014, Tomas Hozza wrote: > > > > > 1. Imagine you boot up the system. NM is started before dnssec-trigger > > and unbound, therefore all informations about domains provided by > > existing connections are discarded. > > What information is provided and disgarded? You mean NM tries to > configure a domani forward and since no unbound is running the > add_forward is lost? If so, why are we not starting unbound DNS before > NM? Exactly like you've said, NM dispatcher runs the script that tries to configure forward domain running the add_forward, but since unbound is not running and the information is discarded. Before there was no way how to get the information from NM after the interface (or connection) was already up, especially for VPNs. But now there is such a way. As for the idea of starting unbound before NM. I had the same idea right after I realized what was actually happening and experimented whit it. Unfortunately this solution is no feasible due to (systemd) service dependencies. NM needs to be started before the network is fully configured, since itself configures interfaces. The DNS (unbound) has to be started after the network interfaces are configured. I tried it and it didn't work due to these dependencies. > > So if you were already at the boot time connected to a network that > > provides domains via DHCP no forward zones were added for such domains > > into the unbound. > > I was not aware we are unconditionally forwarding random DHCP domains to > random resolvers. You mean if I create a wifi network with search domain > redhat.com and the IP of my nameserver, you are going to redirect all my > DNS lookups? That would be a security problem. The reason for such behaviour is described later (marked with *). However I'm aware of the implication, therefore I think the DNSSEC validation of such forward zones should be enabled by default to prevent possible DNS answers manipulation. User needs to intentionally turn the validation off. At the current implementation I don't see any reasonable solution how to enable the user to explicitly specify for which connections they want to configure forward zones. Other thing is that you are connecting to some network (wifi for example) intentionally. It's not like your notebook is randomly connecting to any network it discovers by default. > While dhcp domains from static LAN networks can usually be trusted, I > don't want to trust dhcp domains from random wifi access points. And the > only possibly use for that I see is to get past the hotspot/login page, > which I believe should have its own web page and DNS handling anyway. > > > Till now there was no possible way how one could get those information > > from NM during the runtime, especially for VPN, but this is already > > fixed in the latest NM git snapshot. > > I don't understand how your VPN can be up before your local DNS server > is up? One would assume you need a DNS server to reach the VPN server? One can use IP address instead of domain name in this case, but anyway in this case it was not meant for VPN connection, but any other connection. For example in the RH office, the wired connection provides you "redhat.com" domain. (*) In case local (internal) NS are not fully DNSSEC capable, dnssec-trigger would not use them for resolving. But you still may want to use them at least for the provided domain, hence the forward zone for a connection provided domain(s) and not only for VPNs. > > 2. Imagine you have two connections that provide the same domain. > > One is VPN and one is not. In current situation the last connected > > connection and by it provided NS would be used for that domain. > > That is wrong. Luckilly, currently at least the IPsec VPN duplicates > this DNS effort and will overwrite the NM behaviour. I agree, hence I see the need for correcting this behaviour. > > By my opinion and by what I discussed with Pavel Simerda it makes > > more sense for the VPN to be preferred. > > More strongly, why did NM accept that first domain to begin with? I agree with you that NM behaviour is not correct in this case. Unfortunately I'm not NM developer and therefore not a good person to discuss the NM behaviour with. > > 3. Imagine you have two connections that provide the same domain. > > One is VPN and one is not. Forward zone for provided domain has > > been added into unbound by the dispatcher script. If you then > > disconnect the connection for which the forward zone has been > > configured, it is removed by the dispatcher script. However even > > there is another connection providing the same domain the > > forward zone is not added, because it is added only if the connection > > goes UP. > > That I can see as a problem only when we are on a "secure" LAN that > provided the dns forwards. It should never apply to wifi. And for that, > NM has all the information when it is notified that the VPN goes down, > to redo the DNS forward. You may have a "secured corporate" wifi connection the same situation as described in (*) can happen. I'm not sure there is any way how to distinguish it from regular secured wifi connection. For the information NM has when VPN goes down, it is correct. However in the current shell script it was not implemented in any way, since the script only removed the forward zone for the connection that went down, but didn't add new forward for existing connection if it provided the same domain. The forward domain was added only for connection going up, since it would require getting runtime information from NM for all active connections and extended logic - the thing the new python script does. > > Due to these reasons I rewrote the script into Python and used > > the NM libnm-glib Python bindings that allow one to get information > > for current active connections from NM. > > Great! Having a better NM intergration is awesome! > > > The new script works as follows: > > > > A. It gets all active connections from NM that have provided > > some NS. > > What does this mean? A NM manual configuration? Or a combination of > receiving domain and DNS servers from DHCP? This behaviour basically didn't change since previous dispatcher scripts. FWIK active connection in NM terminology means connection that is active and connected at the time you're checking it. It's configuration may be fully dynamic (information provided via DHCP), static (if configured manually in NM) or combination. So in most cases it is information provided by DHCP, but this may not be fully true in all cases. I hope Pavel Simerda will correct me if I'm wrong in this. > > It gets information if the connection is VPN, > > or is marked as default connection by NM (for IPv4 or IPv6). > > > > B. Global forwarder are configured using dnssec-trigger-control. > > 1. Only active connections marked by NM as default (4 or 6) > > are filtered. > > I'm not sure what this means? Is a connection "eth0"? Or "StarBucks > wifi" ? What makes a 'connection' a 'default' ? >From my point of view it is some NM magic. The flag is based on some NM logic and prioritization. Default means that the connection should be used by default for outgoing communication (it may be different for IPv4 and IPv6). In case you have wifi and wired connection, the wired connection is always preferred. > > 2. NSs provided by such connections are combined into one list > > (both IPv4 and IPv6 addresses) and passed to dnssec-trigger-control. > > > > C. Forward zones for domains provided by active connections are configured > > using unbound-control > > 1. Only active connections with domains provided are filtered. > > What is a "filter" in terms of "connection"? domain names received from > DHCP? This is more of a Python terminology. It means that only active connections with provided (forward) domains are used for further logic. This is due to it doesn't make much sense to work with a connection that does not provide any domain in terms of Forward zones addition/deletion. > Does dnssec-triggerd still have a "sane" state when you reconfigure > unbound manually outside dnssec-triggerd? I assume those unbound-control > calls are never for the global DNS resolving, but only specific domains? > Like when my DHCP server returns my nameserver and a domains ".", I > assume you will not send an unbound_control forward_add for "." ? > > > 4. Previously configured Forward zones for connections which UUID > > is different than the UUID of connection that should be used > > for the domain are removed from unbound. > > - example: you are connected via wire to network that provides > > "example.com" domain therefore it has been configured as forward > > into unbound. > > As I said, I think this is dangerous. I don't want random networks to > start giving me DNS server redirects for "google.com" or other things. > While I'm willing to say that for a wire you can do this, I don't really > want this behaviour per default for wifi. I don't really control what > wifis my laptop connects to. What about the "secured corporate" wifi network situation I described before? I personally see a use case also in wifi networks, but I agree that it is hard to come up with a really good solution. I'm willing to improve it in some way if you have any constructive ideas (in the constraints of current possibilities), but stopping the addition of forward zones for wifi connections completely is also not a good idea by my opinion. > > I also extracted the option for whether to configure secured or unsecured > > forward zones to /etc/dnssec.conf file. This was done so the option > > can be reused also by other tools, not only dnssec-trigger, as we (me and > > Pavel Simerda) plan to implement equivalent functionality and unbound > > plugin for NetworkManager. The configuration file does not need > > to exist, the default behaviour is also specified in the script itself. > > The option name is "validate_connection_provided_zones" since from our > > point of view it is more self-explanatory than "forward zones" used unbound > > terminology. > > I'd be happier if this would become an option one can set in the network > properties of NM, "allow network to forward 'redhat.com' to its supplied > nameservers", with a default of off, and possible a prompting for LANs > and and no prompting for wifi, with the only wifi option to manually go > into the network properties. I am not sure I see the value of doing this > seperately from NM in a new config file. I agree with this. Unfortunately at the moment it is not possible in the NM UI and will require even further NM integration (which is planned, but will not happen over night). The plan is that the configuration file could be at least partially used by NM in the future. This way we will be able to at least provide some backward compatibility with the current solution that uses dnssec-trigger. Therefore we think it is not a good approach to leave the configuration solely in dnssec-trigger dispatcher script. The motivation here is to improve the current situation due to some issues I described before, in the constraints of current possibilities, rather than implement the best possible solution later on (which will anyway happen). Regards, Tomas Hozza From psimerda at redhat.com Wed Jan 22 11:16:18 2014 From: psimerda at redhat.com (Pavel Simerda) Date: Wed, 22 Jan 2014 06:16:18 -0500 (EST) Subject: [Dnssec-trigger] New dnssec-trigger NM dispatcher script In-Reply-To: <173547297.2792734.1390384079820.JavaMail.root@redhat.com> References: <83642376.2585231.1390318401718.JavaMail.root@redhat.com> <173547297.2792734.1390384079820.JavaMail.root@redhat.com> Message-ID: <591128496.2806501.1390389378512.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Tomas Hozza" > To: "Paul Wouters" > Cc: dnssec-trigger at NLnetLabs.nl, "Juraj Marko" , "Pavel Simerda" > Sent: Wednesday, January 22, 2014 10:47:59 AM > Subject: Re: [Dnssec-trigger] New dnssec-trigger NM dispatcher script > > Hi Paul. > > Thank you for your feedback. > > ----- Original Message ----- > > On Tue, 21 Jan 2014, Tomas Hozza wrote: > > > > > > > > 1. Imagine you boot up the system. NM is started before dnssec-trigger > > > and unbound, therefore all informations about domains provided by > > > existing connections are discarded. > > > > What information is provided and disgarded? You mean NM tries to > > configure a domani forward and since no unbound is running the > > add_forward is lost? If so, why are we not starting unbound DNS before > > NM? > > Exactly like you've said, NM dispatcher runs the script that tries to > configure forward domain running the add_forward, but since unbound is > not running and the information is discarded. Before there was no way > how to get the information from NM after the interface (or connection) > was already up, especially for VPNs. But now there is such a way. > > As for the idea of starting unbound before NM. I had the same idea right > after I realized what was actually happening and experimented whit it. > Unfortunately this solution is no feasible due to (systemd) service > dependencies. > > NM needs to be started before the network is fully configured, since itself > configures interfaces. The DNS (unbound) has to be started after the network > interfaces are configured. I tried it and it didn't work due to these > dependencies. Actually this is a long discussed dependency issue. Even some very basic networking services assume that the network is ready at the time they start, while they could technically start at *any* time provided that they can cope with changing network configuration (which they should do anyway). Fortunately this is generally fixable and may even already be fixed in unbound (I have no knowledge about that, yet). Please speak up if you have reasons to believe that any configuration of unbound is capable of running before NetworkManager. Either way, Tom??'s work led to discovery of bugs and missing features in NetworkManager, which are now fixed. NetworkManager is now capable of providing (almost) all relevant information it has, which is basically the list of connections and their associated static and dynamic configuration including information from DHCP, VPNs. You can now access that information at any time whether you have any of them already or not. > > > So if you were already at the boot time connected to a network that > > > provides domains via DHCP no forward zones were added for such domains > > > into the unbound. > > > > I was not aware we are unconditionally forwarding random DHCP domains to > > random resolvers. We discussed it thoroughly and we basically came to a conclusion that you have to distinguish levels of DNSSEC support and their relation to the real world configurations. A simplified version follows: 0) No validation. 1) Validation with exceptions useful for applications supporting the AD flag. 2) Validation of all DNS queries by all applications. The current status of virtually all realistic deployments is #0, as is the default for distributions. Switching to anything else than "no validation" previously meant many everyday networking usecases would stop working which is not acceptable. In my view, Tom??'s patch employs #2 (the strict mode) by default and makes it work with many more use cases than before. Basically, it works with both *global internet* and *private networks covered by global DNSSEC validation tree*. Unfortunately there are many networks that need to be accessed without validation and that's where #1 comes into the play. > > You mean if I create a wifi network with search domain > > redhat.com and the IP of my nameserver, you are going to redirect all my > > DNS lookups? That would be a security problem. If we accept the levels written above, for level #2 that would indeed be a security problem. But for level #1 that would be acceptable (note the requirement to check the AD flag by application). I understand that is not much, but at least it allows *selected* applications to make full use of DNSSEC while not breaking everyday user experience and that encourages DNSSEC deployment both on the client side and on the server side. Also there are many machines that aren't affected by the road warrior use cases and can make full benefit of #2 for various reasons. Tom??'s patch does't affect the validation in that case but makes it possible to still dynamically configure DNS forwarders for specific local zones. > The reason for such behaviour is described later (marked with *). However > I'm aware of the implication, therefore I think the DNSSEC validation of > such forward zones should be enabled by default to prevent possible > DNS answers manipulation. User needs to intentionally turn the validation > off. > > At the current implementation I don't see any reasonable solution how > to enable the user to explicitly specify for which connections they want > to configure forward zones. I think this would be best handled in NetworkManager itself, which is the natural follow-up after we get at least basic DNSSEC (and split DNS) support in distributions (which we hope will be accelerated by Tom??'s contributions where even the most conservative distributions might consider #1 by default). > Other thing is that you are connecting to some network (wifi for example) > intentionally. It's not like your notebook is randomly connecting to > any network it discovers by default. > > > While dhcp domains from static LAN networks can usually be trusted, I > > don't want to trust dhcp domains from random wifi access points. And the > > only possibly use for that I see is to get past the hotspot/login page, > > which I believe should have its own web page and DNS handling anyway. > > > > > Till now there was no possible way how one could get those information > > > from NM during the runtime, especially for VPN, but this is already > > > fixed in the latest NM git snapshot. > > > > I don't understand how your VPN can be up before your local DNS server > > is up? One would assume you need a DNS server to reach the VPN server? > > One can use IP address instead of domain name in this case, but anyway > in this case it was not meant for VPN connection, but any other connection. > For example in the RH office, the wired connection provides you "redhat.com" > domain. > > (*) > In case local (internal) NS are not fully DNSSEC capable, dnssec-trigger > would > not use them for resolving. But you still may want to use them at least > for the provided domain, hence the forward zone for a connection provided > domain(s) and not only for VPNs. > > > > 2. Imagine you have two connections that provide the same domain. > > > One is VPN and one is not. In current situation the last connected > > > connection and by it provided NS would be used for that domain. > > > > That is wrong. Luckilly, currently at least the IPsec VPN duplicates > > this DNS effort and will overwrite the NM behaviour. > > I agree, hence I see the need for correcting this behaviour. > > > > By my opinion and by what I discussed with Pavel Simerda it makes > > > more sense for the VPN to be preferred. > > > > More strongly, why did NM accept that first domain to begin with? > > I agree with you that NM behaviour is not correct in this case. > Unfortunately I'm not NM developer and therefore not a good person > to discuss the NM behaviour with. > > > > 3. Imagine you have two connections that provide the same domain. > > > One is VPN and one is not. Forward zone for provided domain has > > > been added into unbound by the dispatcher script. If you then > > > disconnect the connection for which the forward zone has been > > > configured, it is removed by the dispatcher script. However even > > > there is another connection providing the same domain the > > > forward zone is not added, because it is added only if the connection > > > goes UP. > > > > That I can see as a problem only when we are on a "secure" LAN that > > provided the dns forwards. It should never apply to wifi. And for that, > > NM has all the information when it is notified that the VPN goes down, > > to redo the DNS forward. > > You may have a "secured corporate" wifi connection the same situation > as described in (*) can happen. I'm not sure there is any > way how to distinguish it from regular secured wifi connection. > > For the information NM has when VPN goes down, it is correct. However > in the current shell script it was not implemented in any way, since > the script only removed the forward zone for the connection that went > down, but didn't add new forward for existing connection if it provided > the same domain. > > The forward domain was added only for connection going up, since it would > require getting runtime information from NM for all active connections > and extended logic - the thing the new python script does. > > > > Due to these reasons I rewrote the script into Python and used > > > the NM libnm-glib Python bindings that allow one to get information > > > for current active connections from NM. > > > > Great! Having a better NM intergration is awesome! +1 > > > The new script works as follows: > > > > > > A. It gets all active connections from NM that have provided > > > some NS. > > > > What does this mean? A NM manual configuration? Or a combination of > > receiving domain and DNS servers from DHCP? > > This behaviour basically didn't change since previous dispatcher scripts. > > FWIK active connection in NM terminology means connection that is > active and connected at the time you're checking it. It's configuration > may be fully dynamic (information provided via DHCP), static (if configured > manually in NM) or combination. > > So in most cases it is information provided by DHCP, but this may not > be fully true in all cases. I hope Pavel Simerda will correct me if I'm > wrong in this. +1 You could theoretically distinguish the source of the configuration (contribution to NM may be needed, though) but my impression is that it would be better handled in NetworkManager itself. In my opinion, NetworkManager should be the service that decides whether a forward zone would be validated or would get an exception of being unvalidated. That's also why we are using /etc/dnssec.conf which is currently read by the dnssec-trigger script but could later be taken over by NetworkManager entirely, with connection configuration providing more detailed DNSSEC options. > > > It gets information if the connection is VPN, > > > or is marked as default connection by NM (for IPv4 or IPv6). > > > > > > B. Global forwarder are configured using dnssec-trigger-control. > > > 1. Only active connections marked by NM as default (4 or 6) > > > are filtered. > > > > I'm not sure what this means? Is a connection "eth0"? Or "StarBucks > > wifi" ? What makes a 'connection' a 'default' ? When a connection is selected as 'default' or 'a default routing connection' for IPv4 and/or IPv6 traffic, a default route is set up to *route traffic by default through that connection* and to query DNS by default via servers beloning to that connection*. It's pretty simple unless you get different connections default for IPv4 and IPv6 where NetworkManager doesn't tell you which DNS servers should be used. > From my point of view it is some NM magic. The flag is based on some > NM logic and prioritization. Default means that the connection should be > used by default for outgoing communication (it may be different for IPv4 > and IPv6). In case you have wifi and wired connection, the wired connection > is always preferred. While the preference affects default connection choice, it's not entirely the same. You can actually mark a connection so that it never becomes default and so you can use it only for accessing local resources determined by IP subnets and DNS zones. > > > 2. NSs provided by such connections are combined into one list > > > (both IPv4 and IPv6 addresses) and passed to dnssec-trigger-control. > > > > > > C. Forward zones for domains provided by active connections are > > > configured > > > using unbound-control > > > 1. Only active connections with domains provided are filtered. > > > > What is a "filter" in terms of "connection"? domain names received from > > DHCP? > > This is more of a Python terminology. It means that only active connections > with provided (forward) domains are used for further logic. This is due to > it doesn't make much sense to work with a connection that does not provide > any domain in terms of Forward zones addition/deletion. > > > Does dnssec-triggerd still have a "sane" state when you reconfigure > > unbound manually outside dnssec-triggerd? I assume those unbound-control > > calls are never for the global DNS resolving, but only specific domains? > > Like when my DHCP server returns my nameserver and a domains ".", I > > assume you will not send an unbound_control forward_add for "." ? > > > > > 4. Previously configured Forward zones for connections which UUID > > > is different than the UUID of connection that should be used > > > for the domain are removed from unbound. > > > - example: you are connected via wire to network that provides > > > "example.com" domain therefore it has been configured as forward > > > into unbound. > > > > As I said, I think this is dangerous. I don't want random networks to > > start giving me DNS server redirects for "google.com" or other things. > > While I'm willing to say that for a wire you can do this, I don't really > > want this behaviour per default for wifi. By blocking this on wifi, you're introducing a regression in functionality. While that may be acceptable in some cases, it doesn't mean it will be acceptable for distributions to be used by default. By not using local DNS servers and/or forcing validation of local DNS domains, you're effectively blocking the user from accessing the local resources, whatever they are. We aren't saying dnssec-trigger should permit that by default (Tom?? actually did the opposite) but we want to allow the deployment of DNSSEC (at least as specified in level #1 above) without disturbing the everyday networking use cases. > > I don't really control what > > wifis my laptop connects to. > > What about the "secured corporate" wifi network situation I described before? > I personally see a use case also in wifi networks, but I agree that it is > hard > to come up with a really good solution. I'm willing to improve it in some way > if you have any constructive ideas (in the constraints of current > possibilities), > but stopping the addition of forward zones for wifi connections completely is > also not a good idea by my opinion. +1 Basically if you turn off validation for local zones, you should be able to resolve local resources as you did without dnssec-trigger installed. Otherwise we're killing the solution for 99.9% of potential users. > > > I also extracted the option for whether to configure secured or unsecured > > > forward zones to /etc/dnssec.conf file. This was done so the option > > > can be reused also by other tools, not only dnssec-trigger, as we (me and > > > Pavel Simerda) plan to implement equivalent functionality and unbound > > > plugin for NetworkManager. The configuration file does not need > > > to exist, the default behaviour is also specified in the script itself. > > > The option name is "validate_connection_provided_zones" since from our > > > point of view it is more self-explanatory than "forward zones" used > > > unbound > > > terminology. > > > > I'd be happier if this would become an option one can set in the network > > properties of NM,"allow network to forward 'redhat.com' to its supplied > > nameservers", I agree with that. It's in the scope of NetworkManager and we definitely count with advanced options in NetworkManager. You can treat the script simply as a way to transport the resulting configuration from NetworkManager to dnssec-trigger and unbound and Tom??'s version already does that pretty well. There are two improvements that should IMO follow up, one is that NetworkManager should provide all the necessary configuration options for filtering and marking the zones and the other is that NetworkManager should eventually consume the script so that its functionality is an intrinsic part of NetworkManager. But none of them will happen this month ;). > > with a default of off, and possible a prompting for LANs > > and and no prompting for wifi, with the only wifi option to manually go > > into the network properties. I am not sure I see the value of doing this > > seperately from NM in a new config file. > > I agree with this. Unfortunately at the moment it is not possible in the > NM UI and will require even further NM integration (which is planned, > but will not happen over night). > > The plan is that the configuration file could be at least partially > used by NM in the future. This way we will be able to at least provide some > backward compatibility with the current solution that uses dnssec-trigger. > Therefore we think it is not a good approach to leave the configuration > solely in dnssec-trigger dispatcher script. > > The motivation here is to improve the current situation due to some > issues I described before, in the constraints of current possibilities, > rather than implement the best possible solution later on (which will > anyway happen). > > > Regards, > > Tomas Hozza Hope that helps. Cheers, Pavel From wouter at nlnetlabs.nl Wed Jan 22 13:09:11 2014 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Wed, 22 Jan 2014 14:09:11 +0100 Subject: [Dnssec-trigger] New dnssec-trigger NM dispatcher script In-Reply-To: <591128496.2806501.1390389378512.JavaMail.root@redhat.com> References: <83642376.2585231.1390318401718.JavaMail.root@redhat.com> <173547297.2792734.1390384079820.JavaMail.root@redhat.com> <591128496.2806501.1390389378512.JavaMail.root@redhat.com> Message-ID: <52DFC2F7.7070905@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Pavel, On 01/22/2014 12:16 PM, Pavel Simerda wrote: >> Hi Paul. >> >> Thank you for your feedback. >> >> ----- Original Message ----- >>> On Tue, 21 Jan 2014, Tomas Hozza wrote: >>>> 1. Imagine you boot up the system. NM is started before >>>> dnssec-trigger and unbound, therefore all informations about >>>> domains provided by existing connections are discarded. >>> >>> What information is provided and disgarded? You mean NM tries >>> to configure a domani forward and since no unbound is running >>> the add_forward is lost? If so, why are we not starting unbound >>> DNS before NM? >> >> Exactly like you've said, NM dispatcher runs the script that >> tries to configure forward domain running the add_forward, but >> since unbound is not running and the information is discarded. >> Before there was no way how to get the information from NM after >> the interface (or connection) was already up, especially for >> VPNs. But now there is such a way. >> >> As for the idea of starting unbound before NM. I had the same >> idea right after I realized what was actually happening and >> experimented whit it. Unfortunately this solution is no feasible >> due to (systemd) service dependencies. >> >> NM needs to be started before the network is fully configured, >> since itself configures interfaces. The DNS (unbound) has to be >> started after the network interfaces are configured. I tried it >> and it didn't work due to these dependencies. > > Actually this is a long discussed dependency issue. Even some very > basic networking services assume that the network is ready at the > time they start, while they could technically start at *any* time > provided that they can cope with changing network configuration > (which they should do anyway). Fortunately this is generally > fixable and may even already be fixed in unbound (I have no > knowledge about that, yet). Please speak up if you have reasons to > believe that any configuration of unbound is capable of running > before NetworkManager. Unbound may be able to start with interface-automatic: yes enabled (for incoming). It then is an open resolver that serves everyone. The default outgoing interfaces (0.0.0.0 and ::0) work fine. I think this can start before the network is up. When interfaces come up, unbound starts to serve port53 DNS to them. A side effect would be an open resolver accessible from the outside, because your config now is that unbound binds 127.0.0.1. However, the access-control statements are checked after that, and there you can say that 127.0.0.1 gets service and other addresses are REFUSED (or dropped) (and also firewall port53 is another option). It would conflict for people that additionally want to run a DNS server for the outside world, i.e. on port53 on another interface. But the OS may also bind the more-specific interface for that other daemon (I think this depends on socket options). Best regards, Wouter > > Either way, Tom??'s work led to discovery of bugs and missing > features in NetworkManager, which are now fixed. NetworkManager is > now capable of providing (almost) all relevant information it has, > which is basically the list of connections and their associated > static and dynamic configuration including information from DHCP, > VPNs. You can now access that information at any time whether you > have any of them already or not. > >>>> So if you were already at the boot time connected to a >>>> network that provides domains via DHCP no forward zones were >>>> added for such domains into the unbound. >>> >>> I was not aware we are unconditionally forwarding random DHCP >>> domains to random resolvers. > > We discussed it thoroughly and we basically came to a conclusion > that you have to distinguish levels of DNSSEC support and their > relation to the real world configurations. A simplified version > follows: > > 0) No validation. 1) Validation with exceptions useful for > applications supporting the AD flag. 2) Validation of all DNS > queries by all applications. > > The current status of virtually all realistic deployments is #0, as > is the default for distributions. Switching to anything else than > "no validation" previously meant many everyday networking usecases > would stop working which is not acceptable. > > In my view, Tom??'s patch employs #2 (the strict mode) by default > and makes it work with many more use cases than before. Basically, > it works with both *global internet* and *private networks covered > by global DNSSEC validation tree*. Unfortunately there are many > networks that need to be accessed without validation and that's > where #1 comes into the play. > >>> You mean if I create a wifi network with search domain >>> redhat.com and the IP of my nameserver, you are going to >>> redirect all my DNS lookups? That would be a security problem. > > If we accept the levels written above, for level #2 that would > indeed be a security problem. But for level #1 that would be > acceptable (note the requirement to check the AD flag by > application). I understand that is not much, but at least it allows > *selected* applications to make full use of DNSSEC while not > breaking everyday user experience and that encourages DNSSEC > deployment both on the client side and on the server side. > > Also there are many machines that aren't affected by the road > warrior use cases and can make full benefit of #2 for various > reasons. Tom??'s patch does't affect the validation in that case > but makes it possible to still dynamically configure DNS forwarders > for specific local zones. > >> The reason for such behaviour is described later (marked with *). >> However I'm aware of the implication, therefore I think the >> DNSSEC validation of such forward zones should be enabled by >> default to prevent possible DNS answers manipulation. User needs >> to intentionally turn the validation off. >> >> At the current implementation I don't see any reasonable solution >> how to enable the user to explicitly specify for which >> connections they want to configure forward zones. > > I think this would be best handled in NetworkManager itself, which > is the natural follow-up after we get at least basic DNSSEC (and > split DNS) support in distributions (which we hope will be > accelerated by Tom??'s contributions where even the most > conservative distributions might consider #1 by default). > >> Other thing is that you are connecting to some network (wifi for >> example) intentionally. It's not like your notebook is randomly >> connecting to any network it discovers by default. >> >>> While dhcp domains from static LAN networks can usually be >>> trusted, I don't want to trust dhcp domains from random wifi >>> access points. And the only possibly use for that I see is to >>> get past the hotspot/login page, which I believe should have >>> its own web page and DNS handling anyway. >>> >>>> Till now there was no possible way how one could get those >>>> information from NM during the runtime, especially for VPN, >>>> but this is already fixed in the latest NM git snapshot. >>> >>> I don't understand how your VPN can be up before your local DNS >>> server is up? One would assume you need a DNS server to reach >>> the VPN server? >> >> One can use IP address instead of domain name in this case, but >> anyway in this case it was not meant for VPN connection, but any >> other connection. For example in the RH office, the wired >> connection provides you "redhat.com" domain. >> >> (*) In case local (internal) NS are not fully DNSSEC capable, >> dnssec-trigger would not use them for resolving. But you still >> may want to use them at least for the provided domain, hence the >> forward zone for a connection provided domain(s) and not only for >> VPNs. >> >>>> 2. Imagine you have two connections that provide the same >>>> domain. One is VPN and one is not. In current situation the >>>> last connected connection and by it provided NS would be used >>>> for that domain. >>> >>> That is wrong. Luckilly, currently at least the IPsec VPN >>> duplicates this DNS effort and will overwrite the NM >>> behaviour. >> >> I agree, hence I see the need for correcting this behaviour. >> >>>> By my opinion and by what I discussed with Pavel Simerda it >>>> makes more sense for the VPN to be preferred. >>> >>> More strongly, why did NM accept that first domain to begin >>> with? >> >> I agree with you that NM behaviour is not correct in this case. >> Unfortunately I'm not NM developer and therefore not a good >> person to discuss the NM behaviour with. >> >>>> 3. Imagine you have two connections that provide the same >>>> domain. One is VPN and one is not. Forward zone for provided >>>> domain has been added into unbound by the dispatcher script. >>>> If you then disconnect the connection for which the forward >>>> zone has been configured, it is removed by the dispatcher >>>> script. However even there is another connection providing >>>> the same domain the forward zone is not added, because it is >>>> added only if the connection goes UP. >>> >>> That I can see as a problem only when we are on a "secure" LAN >>> that provided the dns forwards. It should never apply to wifi. >>> And for that, NM has all the information when it is notified >>> that the VPN goes down, to redo the DNS forward. >> >> You may have a "secured corporate" wifi connection the same >> situation as described in (*) can happen. I'm not sure there is >> any way how to distinguish it from regular secured wifi >> connection. >> >> For the information NM has when VPN goes down, it is correct. >> However in the current shell script it was not implemented in any >> way, since the script only removed the forward zone for the >> connection that went down, but didn't add new forward for >> existing connection if it provided the same domain. >> >> The forward domain was added only for connection going up, since >> it would require getting runtime information from NM for all >> active connections and extended logic - the thing the new python >> script does. >> >>>> Due to these reasons I rewrote the script into Python and >>>> used the NM libnm-glib Python bindings that allow one to get >>>> information for current active connections from NM. >>> >>> Great! Having a better NM intergration is awesome! > > +1 > >>>> The new script works as follows: >>>> >>>> A. It gets all active connections from NM that have provided >>>> some NS. >>> >>> What does this mean? A NM manual configuration? Or a >>> combination of receiving domain and DNS servers from DHCP? >> >> This behaviour basically didn't change since previous dispatcher >> scripts. >> >> FWIK active connection in NM terminology means connection that >> is active and connected at the time you're checking it. It's >> configuration may be fully dynamic (information provided via >> DHCP), static (if configured manually in NM) or combination. >> >> So in most cases it is information provided by DHCP, but this may >> not be fully true in all cases. I hope Pavel Simerda will correct >> me if I'm wrong in this. > > +1 > > You could theoretically distinguish the source of the configuration > (contribution to NM may be needed, though) but my impression is > that it would be better handled in NetworkManager itself. In my > opinion, NetworkManager should be the service that decides whether > a forward zone would be validated or would get an exception of > being unvalidated. That's also why we are using /etc/dnssec.conf > which is currently read by the dnssec-trigger script but could > later be taken over by NetworkManager entirely, with connection > configuration providing more detailed DNSSEC options. > >>>> It gets information if the connection is VPN, or is marked as >>>> default connection by NM (for IPv4 or IPv6). >>>> >>>> B. Global forwarder are configured using >>>> dnssec-trigger-control. 1. Only active connections marked by >>>> NM as default (4 or 6) are filtered. >>> >>> I'm not sure what this means? Is a connection "eth0"? Or >>> "StarBucks wifi" ? What makes a 'connection' a 'default' ? > > When a connection is selected as 'default' or 'a default routing > connection' for IPv4 and/or IPv6 traffic, a default route is set up > to *route traffic by default through that connection* and to query > DNS by default via servers beloning to that connection*. It's > pretty simple unless you get different connections default for IPv4 > and IPv6 where NetworkManager doesn't tell you which DNS servers > should be used. > >> From my point of view it is some NM magic. The flag is based on >> some NM logic and prioritization. Default means that the >> connection should be used by default for outgoing communication >> (it may be different for IPv4 and IPv6). In case you have wifi >> and wired connection, the wired connection is always preferred. > > While the preference affects default connection choice, it's not > entirely the same. You can actually mark a connection so that it > never becomes default and so you can use it only for accessing > local resources determined by IP subnets and DNS zones. > >>>> 2. NSs provided by such connections are combined into one >>>> list (both IPv4 and IPv6 addresses) and passed to >>>> dnssec-trigger-control. >>>> >>>> C. Forward zones for domains provided by active connections >>>> are configured using unbound-control 1. Only active >>>> connections with domains provided are filtered. >>> >>> What is a "filter" in terms of "connection"? domain names >>> received from DHCP? >> >> This is more of a Python terminology. It means that only active >> connections with provided (forward) domains are used for further >> logic. This is due to it doesn't make much sense to work with a >> connection that does not provide any domain in terms of Forward >> zones addition/deletion. >> >>> Does dnssec-triggerd still have a "sane" state when you >>> reconfigure unbound manually outside dnssec-triggerd? I assume >>> those unbound-control calls are never for the global DNS >>> resolving, but only specific domains? Like when my DHCP server >>> returns my nameserver and a domains ".", I assume you will not >>> send an unbound_control forward_add for "." ? >>> >>>> 4. Previously configured Forward zones for connections which >>>> UUID is different than the UUID of connection that should be >>>> used for the domain are removed from unbound. - example: you >>>> are connected via wire to network that provides "example.com" >>>> domain therefore it has been configured as forward into >>>> unbound. >>> >>> As I said, I think this is dangerous. I don't want random >>> networks to start giving me DNS server redirects for >>> "google.com" or other things. While I'm willing to say that for >>> a wire you can do this, I don't really want this behaviour per >>> default for wifi. > > By blocking this on wifi, you're introducing a regression in > functionality. While that may be acceptable in some cases, it > doesn't mean it will be acceptable for distributions to be used by > default. By not using local DNS servers and/or forcing validation > of local DNS domains, you're effectively blocking the user from > accessing the local resources, whatever they are. We aren't saying > dnssec-trigger should permit that by default (Tom?? actually did > the opposite) but we want to allow the deployment of DNSSEC (at > least as specified in level #1 above) without disturbing the > everyday networking use cases. > >>> I don't really control what wifis my laptop connects to. >> >> What about the "secured corporate" wifi network situation I >> described before? I personally see a use case also in wifi >> networks, but I agree that it is hard to come up with a really >> good solution. I'm willing to improve it in some way if you have >> any constructive ideas (in the constraints of current >> possibilities), but stopping the addition of forward zones for >> wifi connections completely is also not a good idea by my >> opinion. > > +1 > > Basically if you turn off validation for local zones, you should be > able to resolve local resources as you did without dnssec-trigger > installed. Otherwise we're killing the solution for 99.9% of > potential users. > >>>> I also extracted the option for whether to configure secured >>>> or unsecured forward zones to /etc/dnssec.conf file. This was >>>> done so the option can be reused also by other tools, not >>>> only dnssec-trigger, as we (me and Pavel Simerda) plan to >>>> implement equivalent functionality and unbound plugin for >>>> NetworkManager. The configuration file does not need to >>>> exist, the default behaviour is also specified in the script >>>> itself. The option name is >>>> "validate_connection_provided_zones" since from our point of >>>> view it is more self-explanatory than "forward zones" used >>>> unbound terminology. >>> >>> I'd be happier if this would become an option one can set in >>> the network properties of NM,"allow network to forward >>> 'redhat.com' to its supplied nameservers", > > I agree with that. It's in the scope of NetworkManager and we > definitely count with advanced options in NetworkManager. You can > treat the script simply as a way to transport the resulting > configuration from NetworkManager to dnssec-trigger and unbound and > Tom??'s version already does that pretty well. There are two > improvements that should IMO follow up, one is that NetworkManager > should provide all the necessary configuration options for > filtering and marking the zones and the other is that > NetworkManager should eventually consume the script so that its > functionality is an intrinsic part of NetworkManager. But none of > them will happen this month ;). > >>> with a default of off, and possible a prompting for LANs and >>> and no prompting for wifi, with the only wifi option to >>> manually go into the network properties. I am not sure I see >>> the value of doing this seperately from NM in a new config >>> file. >> >> I agree with this. Unfortunately at the moment it is not possible >> in the NM UI and will require even further NM integration (which >> is planned, but will not happen over night). >> >> The plan is that the configuration file could be at least >> partially used by NM in the future. This way we will be able to >> at least provide some backward compatibility with the current >> solution that uses dnssec-trigger. Therefore we think it is not a >> good approach to leave the configuration solely in dnssec-trigger >> dispatcher script. >> >> The motivation here is to improve the current situation due to >> some issues I described before, in the constraints of current >> possibilities, rather than implement the best possible solution >> later on (which will anyway happen). >> >> >> Regards, >> >> Tomas Hozza > > Hope that helps. > > Cheers, > > Pavel > > _______________________________________________ dnssec-trigger > mailing list dnssec-trigger at NLnetLabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS38L3AAoJEJ9vHC1+BF+NXisP/19LIJ4+XnEvVTiVC7y2iiUh J0eCA5guvMQwEmV7wCAtO/GflgagTYmsjDiHfaNbYheqYbFwhwdXnBdfZlUi5t3N XFa9T3szFr9tyjzrB6G92HlrzHVpuvtXyd2DmhQeF+ouZnO4/z1mh1+jdibgbB8x C17aUD3EUWhYR/pTFx7udt3eFh231sKZN/6z+xrZab8DlbDnJ+QxgLhf4jTU+kA/ XF/Njc+Fp10je/GhOIzB7tvbqQlRBngH/YmhSrfSgfb3N1hiTAYAdIrPR/0ra+g/ HONZyVW672JOO00sA4snICzxky7avomMvBWmU+Jp+znbWeyAbh4Er5aVPCFJ9AXA 0Bj3Q2D9kYPHbQr5qm/eUd6QvV5oNMZDlgE6k5nj30//E+lVyiGycCixOXkNQCvf krN5EHhOvSh4xKXt4UTjiK8Z5IEznTxZV5ODsnfYLrlwDMGiGVTVEBVhxgMW8TTX u7HPm4av82x1e0ZGDEJSj3L4/AEiAZ5+AGUj0bZwb3qbsrnfoi+TcQq127S19LfL GLxsl3rNtrHs9PR9MGLjlawdINZd4wNt16kFlfJLwd506xQ3o/Vk8otw4UDBrwMw Feg/rDkrmbwDq363SIBIOnpHUXWMZaDeXBZzaEG4RjZ36m8X/RB7vBKV2Zk5pUou xsUhWteFvUoi6CRCJKde =ca0b -----END PGP SIGNATURE----- From paul at nohats.ca Wed Jan 22 18:00:32 2014 From: paul at nohats.ca (Paul Wouters) Date: Wed, 22 Jan 2014 13:00:32 -0500 (EST) Subject: [Dnssec-trigger] New dnssec-trigger NM dispatcher script In-Reply-To: <173547297.2792734.1390384079820.JavaMail.root@redhat.com> References: <83642376.2585231.1390318401718.JavaMail.root@redhat.com> <173547297.2792734.1390384079820.JavaMail.root@redhat.com> Message-ID: On Wed, 22 Jan 2014, Tomas Hozza wrote: > What about the "secured corporate" wifi network situation I described before? > I personally see a use case also in wifi networks, but I agree that it is hard > to come up with a really good solution. I'm willing to improve it in some way > if you have any constructive ideas (in the constraints of current possibilities), > but stopping the addition of forward zones for wifi connections completely is > also not a good idea by my opinion. > I agree with this. Unfortunately at the moment it is not possible in the > NM UI and will require even further NM integration (which is planned, > but will not happen over night). > > The plan is that the configuration file could be at least partially > used by NM in the future. This way we will be able to at least provide some > backward compatibility with the current solution that uses dnssec-trigger. > Therefore we think it is not a good approach to leave the configuration > solely in dnssec-trigger dispatcher script. > > The motivation here is to improve the current situation due to some > issues I described before, in the constraints of current possibilities, > rather than implement the best possible solution later on (which will > anyway happen). Let me try and summarize what I think is the problem. You have interpreted the "domain" entry in /etc/resolv.conf as being the LAN's domain and the nameservers from /etc/resolv.conf as being the IP addresses of the nameservers that can resolve the "domain". However, that is not what those entries mean. The "domain" entry means that if you are going to send an unqualified (non-FQDN) query, and you don't get a result, you may try again my apending the "domain" entry. The IP's of nameservers are nothing more than the IP of nameservers. They have no relationship to the "domain" entry whatsoever. On modern systems, these values are populated by DHCP. Thse two interpretations are different, which is the source of the security issues. Sometimes, people have created relationships that _does_ equate these two different interpretations. So if you have a "domain" of "internal.redhat.com" and nameservers 1.2.3.4,5.6.7.8 than it is implied that you can lookup this custom non-world view domain using these nameservers. What you are suggesting is that _all_ networks are like this. While I am saying we should not _always_ assume this. So the design work here is to come up with a scenario that: - Does not degrade security - Does not burden the user with making this choice We mentioned a few possibilities: - Assume ethernet connectivity implies the user's consent in trusting the network, allowing the above assumption to be made - Assume VPN configurations always override LAN settings - What to do with Wifi (we disagree here on what to do) On this last point, I think we have a few policy options we can choose from, compromising based on reducing user interactivity and NM changes: - Wifi is untrusted, never redirect the received "domain" to the received nameserver IP's, unless the user manually tells us to do so [ policy easy to implement, but requires non-trivial NM changes] - If ESSID was known and automatically joined, trust the wifi and make the domain/ns binding [I say this is insecure, because my laptop auto-joins networks it has never been on if the name happens to match, like "linksys" or "PublicWifi", or by active attacks like people setting "redhat.com" on purpose to trick me] - If non-open Wifi, assume trust like physical wire. Eg WPA, EAP. [ I am fine with this ] I hope I clarified that I think we cannot have this resolv.conf mapping of domain name and namesevers IP unconditionally, which is what the current python hook seems to do. Paul From paul at nohats.ca Wed Jan 22 18:13:46 2014 From: paul at nohats.ca (Paul Wouters) Date: Wed, 22 Jan 2014 13:13:46 -0500 (EST) Subject: [Dnssec-trigger] New dnssec-trigger NM dispatcher script In-Reply-To: <52DFC2F7.7070905@nlnetlabs.nl> References: <83642376.2585231.1390318401718.JavaMail.root@redhat.com> <173547297.2792734.1390384079820.JavaMail.root@redhat.com> <591128496.2806501.1390389378512.JavaMail.root@redhat.com> <52DFC2F7.7070905@nlnetlabs.nl> Message-ID: On Wed, 22 Jan 2014, W.C.A. Wijngaards wrote: >> knowledge about that, yet). Please speak up if you have reasons to >> believe that any configuration of unbound is capable of running >> before NetworkManager. > > Unbound may be able to start with interface-automatic: yes enabled > (for incoming). It then is an open resolver that serves everyone. > The default outgoing interfaces (0.0.0.0 and ::0) work fine. I think > this can start before the network is up. When interfaces come up, > unbound starts to serve port53 DNS to them. > > A side effect would be an open resolver accessible from the outside, > because your config now is that unbound binds 127.0.0.1. However, the > access-control statements are checked after that, and there you can > say that 127.0.0.1 gets service and other addresses are REFUSED (or > dropped) (and also firewall port53 is another option). I would be okay with this change. Currently, interface-automatic: is no to comply with the policy of not starting servers without user consent, but if we are making unboudn the default, this indeed makes sense, and we should just configure unbound with localhost ACL's but let it listen on all interfaces. Thanks for this suggestion. > It would conflict for people that additionally want to run a DNS > server for the outside world, i.e. on port53 on another interface. > But the OS may also bind the more-specific interface for that other > daemon (I think this depends on socket options). This might be a problem indeed, especially with KVM/virt-manager and dnsmasq instances that run on vnet* interfaces. I don't know of a solution for this, as dnsmasq is needed for DHCP. Perhaps we could tell dnsmasq to forward all DNS to 127.0.0.1? However, that would expose host DNS changes to the guests. Which I think is okay? Paul From psimerda at redhat.com Thu Jan 23 08:50:08 2014 From: psimerda at redhat.com (Pavel Simerda) Date: Thu, 23 Jan 2014 03:50:08 -0500 (EST) Subject: [Dnssec-trigger] New dnssec-trigger NM dispatcher script In-Reply-To: References: <83642376.2585231.1390318401718.JavaMail.root@redhat.com> <173547297.2792734.1390384079820.JavaMail.root@redhat.com> Message-ID: <1471553176.3094003.1390467008268.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Paul Wouters" > To: "Tomas Hozza" > Cc: dnssec-trigger at NLnetLabs.nl, "Juraj Marko" , "Pavel Simerda" , "Paul > Wouters" > Sent: Wednesday, January 22, 2014 7:00:32 PM > Subject: Re: [Dnssec-trigger] New dnssec-trigger NM dispatcher script > > On Wed, 22 Jan 2014, Tomas Hozza wrote: > > > What about the "secured corporate" wifi network situation I described > > before? > > I personally see a use case also in wifi networks, but I agree that it is > > hard > > to come up with a really good solution. I'm willing to improve it in some > > way > > if you have any constructive ideas (in the constraints of current > > possibilities), > > but stopping the addition of forward zones for wifi connections completely > > is > > also not a good idea by my opinion. > > > I agree with this. Unfortunately at the moment it is not possible in the > > NM UI and will require even further NM integration (which is planned, > > but will not happen over night). > > > > The plan is that the configuration file could be at least partially > > used by NM in the future. This way we will be able to at least provide some > > backward compatibility with the current solution that uses dnssec-trigger. > > Therefore we think it is not a good approach to leave the configuration > > solely in dnssec-trigger dispatcher script. > > > > The motivation here is to improve the current situation due to some > > issues I described before, in the constraints of current possibilities, > > rather than implement the best possible solution later on (which will > > anyway happen). > > Let me try and summarize what I think is the problem. > > You have interpreted the "domain" entry in /etc/resolv.conf as being the > LAN's domain and the nameservers from /etc/resolv.conf as being the IP > addresses of the nameservers that can resolve the "domain". I see what you mean but let me write it correctly, as we don't use /etc/resolv.conf at all: We are using NetworkManager's per-connection nameserver list and domain search list as the list of zones and their respective nameservers. This is the same NetworkManager is doing with their dnsmasq plugin and it's generally called the *split DNS* feature which is necessary to properly talk to local resources on multiple networks. The split DNS feature requires a list of domains and a list of respective nameservers. The protocols used by NetworkManager (e.g. DHCP) typically provide one list of local domain in the DHCP search domain list. Because of that, NetworkManager doesn't distinguish those lists. Without the split DNS feature, NetworkManager magically guesses which of the nameservers should be used to get the best results. Just testing the VPN case, it redirects *all* DNS queries to the VPN name servers even though the VPN isn't designated as a default connection. In fact it mixes all DNS servers it finds together. This is a bad privacy issue at the least as that way the local system leaks visited servers to the VPN name servers. Considering what you see as bad security issues, this is probably one of them as technically any query can be posted to any of the name servers. > However, that is not what those entries mean. The "domain" entry means > that if you are going to send an unqualified (non-FQDN) query, and you > don't get a result, you may try again my apending the "domain" entry. > The IP's of nameservers are nothing more than the IP of nameservers. > They have no relationship to the "domain" entry whatsoever. > On modern systems, these values are populated by DHCP. > > Thse two interpretations are different, which is the source of the > security issues. It's pretty common to identify the security issues and compare them to the status quo instead of making vague claims. I'm afraid that you are focusing on something that technically constitutes a security issue but doesn't affect the security a much. While it may sound appealing to remove the behavior of accepting zone-specific nameservers from untrusted sources, you will still accept *any* IP subnet and thus the network's DHCP server can choose you to deliver packets for specific IPs to the network's router. The security of dynamic configuration would have to be evaluated as a whole, not by just suspecting a security issue. But we have a solution for you anyway, please read on. In my opinion, the world's most important use case for DNSSEC is to use DNSSEC as a glue for other security protocols, not merely as a means to receive the correct A/AAAA records. And for that security to work, the clients must support DNSSEC, DANE and finally TLSA. In this scenario you need a supporting server, a local validating resolver and a supporting user agent. Support for that should have been enabled in distributions years ago and we are still nowhere. The existing solution is not even usable for developer testing unless one wants to dedicate a machine to that. Adding a contact from CZ.NIC where they're working on server-side DNSSEC and tools like DNSSEC validation icon for Firefox. Authentication of all DNS queries even for unsupporting applications is a very appealing feature of DNSSEC and Unbound but that's where the issues with the real world arise. I like this possible feature just as you do but I still think the feature above allowing stuff like DANE is more important and less conflicting and > Sometimes, people have created relationships that _does_ equate these > two different interpretations. So if you have a "domain" of > "internal.redhat.com" and nameservers 1.2.3.4,5.6.7.8 than it is implied > that you can lookup this custom non-world view domain using these > nameservers. What you are suggesting is that _all_ networks are like > this. While I am saying we should not _always_ assume this. > > So the design work here is to come up with a scenario that: > - Does not degrade security What we can do is to disable passing the local forward zones from NetworkManager entirely by default and add a directive to /etc/dnssec.conf to enable it. Would that be acceptable to you? > - Does not burden the user with making this choice The solution doesn't burden the users. The configuration is in /etc/dnssec and is handled by the system administrator who acts according to the local security policy. What about accepting there is no one size that fits all and allowing the various systems to deploy varying degrees of security. > We mentioned a few possibilities: > - Assume ethernet connectivity implies the user's consent in trusting > the network, allowing the above assumption to be made Rationale? Ethernet may well be as dangerous as any other connection. Most systems connect to Ethernet even when locked. > - Assume VPN configurations always override LAN settings Rationale? VPNs are often used just to access resources on a remote network, not always belonging to the same entity. > - What to do with Wifi (we disagree here on what to do) In any case, the contribution brings serious functionality improvements. With the two configuration directives in mind, you may well default to a very strict mode while allowing global configuration of whether to accept zones from connections and whether to enforce validation for them. That would keep dnssec-tigger at maximum security (and limited usability) while allowing for full usability (and security only for supporting applications) if configured so, making DNSSEC usable for people who at least want to test it out. Finer grained control should be IMO handled in NetworkManager. When NetworkManager provides the final lists of domains to be used as local forward zones, dnssec-trigger would switch to using those. I propose to ignore connection types in the script that just copies over NetworkManager's local forward zones and handle the details inside NetworkManager. Until that is done, the /etc/dnssec.conf directives could be used for testing out DNSSEC in a security level sufficient for supporting applications. That would at least enable developers to early-adopt DNSSEC on Linux, which would itself be a great achievement in the current status quo. > On this last point, I think we have a few policy options we can choose > from, compromising based on reducing user interactivity and NM changes: > > - Wifi is untrusted, never redirect the received "domain" to the > received nameserver IP's, unless the user manually tells us to do so > [ policy easy to implement, but requires non-trivial NM changes] > - If ESSID was known and automatically joined, trust the wifi and make > the domain/ns binding [I say this is insecure, because my laptop > auto-joins networks it has never been on if the name happens to match, > like "linksys" or "PublicWifi", or by active attacks like people > setting "redhat.com" on purpose to trick me] > - If non-open Wifi, assume trust like physical wire. Eg WPA, EAP. > [ I am fine with this ] I added some other NetworkManager developers to see that. We can start a bugzilla with NetworkManager and define the fine-grained policy and configuration options there so that it doesn't get lost in the depths of the mailing list. Pavel From thozza at redhat.com Tue Jan 28 12:32:18 2014 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 28 Jan 2014 07:32:18 -0500 (EST) Subject: [Dnssec-trigger] [PATCH] modifications of the new python dispatcher hook In-Reply-To: <2105010686.4185596.1390909556065.JavaMail.root@redhat.com> Message-ID: <153709732.4192553.1390912338306.JavaMail.root@redhat.com> Hi. I'm sending you a patch for the recent new Python NM dispatcher hook. It mostly incorporates improvements based on discussion with Paul Wouters and a recent fix in NM (getting of IPv6 nameservers). It also adds a sample dnssec.conf configuration file that the new hook can read. Note that the current default configuration of the hook is PARANOID. This means that forward zones are validated by default and domains provided by WIFI connections are not configured as forward zones. Regards, Tomas Hozza -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Modify-the-new-Python-script-based-on-Paul-Wouters-f.patch Type: text/x-patch Size: 14388 bytes Desc: not available URL: