Description of problem: Connect to a wireless or other hotspot, which configures some dns server X. Then connect to a corporate VPN over this with OpenVPN. The OpenVPN server provides a DNS server Y, with internally avaliable records. These are unable to be resolved as unbound is still resolving via X. Even setting the DNS server settings in Network Manager by hand, these are ignored by unbound. How reproducible: Always Steps to Reproduce: 1. Connect to some wifi that is unable to see zone data in private.example.com. Test dig @::1 host.private.example.com and you shouldn't see any data. grep -r -n -e '172.24.9.3' /etc/unbound/ should reveal no data (Assuming unbound writes the current resolver anywhere. unbound-control list_forwards shows no data. 2. Connect to the VPN. run unbound-control flush_zone example.com to be sure there is no incorrect data. 3. dig @::1 host.private.example.com Actual results: No data is returned. The external name servers authorative data is in header. Expected results: Unbound would respect the VPN dns server configuration, and use it as a forwarder. (From DHCP or NM)
I don't think unbound actively *ignores* anything here and therefore I don't think it makes sense to file bugs like this with unbound. Integration between Unbound and NetworkManager is currently handled in the dnssec-trigger package, so moving there. Note that this is pretty much new development in upstream dnssec-trigger and it may take a while before getting to Fedora.
William, do you use dnssec-trigger? If not I don't think that unbound will find out by itself that there is a VPN connection. Since unbound uses DNSSEC validation it is desired to use more robust hook solution (like dnssec-trigger), rather just some dumb hook which would forward data from NM (DHCP) to unbound mindlessly. Pavel. I'm not sure that there is an issue in dnssec-trigger, as it sounds that dnssec-trigger was not used in this case at all...
I *am* using dnssec-trigger.
(In reply to William Brown from comment #3) > I *am* using dnssec-trigger. OK then. Can you please verify, there is an acvive connection for the VPN connection using 'nmcli c s' command, and also that the proper domain and nameservers are provided by the connection using 'nmcli c s <connection_UUID>' ? Thnak you.
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test Is what I did to setup (In response to mailing list thread)
nmcli c s a 29def469-dfd3-4683-9e27-565ab7481c53 IP4.DNS[1]: 172.24.X.X IP6.DNS[1]: 2001::X:X Trimmed for obvious reasons: Yes these are here. Listing the forwarders, I see: unbound-control list_forwards . IN forward: 10.0.0.1
(In reply to William Brown from comment #6) > nmcli c s a 29def469-dfd3-4683-9e27-565ab7481c53 > > IP4.DNS[1]: 172.24.X.X > IP6.DNS[1]: 2001::X:X > > Trimmed for obvious reasons: Yes these are here. Listing the forwarders, I > see: > > > unbound-control list_forwards > . IN forward: 10.0.0.1 If there is no domain provided by the VPN, no forward zone will be added into unbound. The reason is that unbound is not able to guess for which domain if should use the VPN provided nameserver. And we don't want to configure the VPN provided nameserver as another global forwarder.
So how does this work with my workplace that has 100s of DNS zones that exist within it's servers. Should they all be advertised by the VPN? We have more than one base domain name, so how can we advertise all these even? Even the VPN I am referencing has about 8 zones on it. Is it really reasonable to expect this? This is a really irrational default. If a VPN provides a DNS forwarder, it *must* become the default. You can't just break the user experience like this. If a network advertises a DNS server it *must* become the default forwarder, because there is no way for you to know or assume that it can advertise all avaliable zones.
If it wasn't clear: When you join the wireless you get the DNS global forwarder X from the wireless. When you join the VPN on top you use the DNS global forwarder Y from the VPN. When you leave the VPN, you revert to the previous forwarder from the wireless X. This is the *only* way to ensure you DO NOT break networks on users. You cannot possible assume that every network in the world, works the way *you* expect it to.
> If a VPN provides a DNS forwarder, it *must* become the default. When the user deliberately choses *not* to use the VPN as the default connection, overriding his decision would not only be wrong but would also introduce security issues not expected by the user. Also, when the user choses *not* to use the VPN as the default connection, then he shouldn't go to bugzilla and complain about the result. (In reply to William Brown from comment #9) > If it wasn't clear: > > When you join the wireless you get the DNS global forwarder X from the > wireless. > > When you join the VPN on top you use the DNS global forwarder Y from the VPN. > > When you leave the VPN, you revert to the previous forwarder from the > wireless X. You just described how it works on Fedora with NetworkManager by default.
(In reply to Pavel Šimerda (pavlix) from comment #10) > > If a VPN provides a DNS forwarder, it *must* become the default. > > When the user deliberately choses *not* to use the VPN as the default > connection, overriding his decision would not only be wrong but would also > introduce security issues not expected by the user. So lets say I have a work network that I set to not be the default route. It doesn't advertise the 100s of DNS names avaliable to it. How do you propose to make this work so it doesn't break for users? > > Also, when the user choses *not* to use the VPN as the default connection, > then he shouldn't go to bugzilla and complain about the result. When a piece of DNS software that will soon become the default breaks a network, that is worthy of a bug. > > (In reply to William Brown from comment #9) > > If it wasn't clear: > > > > When you join the wireless you get the DNS global forwarder X from the > > wireless. > > > > When you join the VPN on top you use the DNS global forwarder Y from the VPN. > > > > When you leave the VPN, you revert to the previous forwarder from the > > wireless X. > > You just described how it works on Fedora with NetworkManager by default. Yes, unsetting use this network for resources only on this network resolves this. But the issue then still remains: For a network that states to only be used for it's own resources / routes, how do you propose to make DNS work for this in this case. Again, I do think this justifies a bug as a proposed default *will* be breaking a "common" network configuration.
(In reply to William Brown from comment #11) > So lets say I have a work network that I set to not be the default route. It > doesn't advertise the 100s of DNS names avaliable to it. How do you propose > to make this work so it doesn't break for users? Propagate a domain that is common for all hosts on your private network (e.g. private.example.com). We are open to suggestion on how can this be solved in a better way. > When a piece of DNS software that will soon become the default breaks a > network, that is worthy of a bug. There is no ultimate solution that will work for everyone. Even what you are suggesting may not suite others that care about forwarding only a proper subset of DNS queries to the proper nameserver if the connection was set to be "used only for resources on that network". Or users that care about DNSSEC and want to use DNSSEC capable frowarder at all costs. Then blindly using a VPN provided server that does not support DNSSEC would break the use-case for such users. The final solution would have to be a compromise, not a solution that solves only your use-case that you think is common. > Yes, unsetting use this network for resources only on this network resolves > this. > > > But the issue then still remains: For a network that states to only be used > for it's own resources / routes, how do you propose to make DNS work for > this in this case. Again, I do think this justifies a bug as a proposed > default *will* be breaking a "common" network configuration. We are open to constructive suggestions...
We should have an option configurable on a per-network basis with NM that allows a network to dump all the cache and take over all the DNS with a global forward. It should not be the default. I think that would require relative minor changes in the software: - Extend NM with this per-network option, including GUI support to set/clear it - Extend dnssec-trigger to check for this option when triggered by a VPN client. I believe we could write these patches and submit them upstream to NM and dnssec-trigger.
> Propagate a domain that is common for all hosts on your private network > (e.g. private.example.com). > > We are open to suggestion on how can this be solved in a better way. We have far too many zones for this. The only common element is . > > The final solution would have to be a compromise, not a solution that solves > only your use-case that you think is common. Additionally, I am willing to guinea pig these issues, and find them, but the students and staff at the institute I work for who move around, use VPN etc may not be so tolerant of these issues, nor as able to diagnose and solve them :) > > We are open to constructive suggestions... I can see a few suggestions. Some are good, some are not. I have detailed these below: A) Maintain the current expected behaviour. Use the DNS from that network as default when you join, even if it's set to "only for that networks resources". B) Allow NM or other tool to list a complete set of networks for me "resources only" that will be translated into forwarders. Perhaps even allow input of an admin provided XML file definition of these. IE I could put in a list of - foo.edu.au. - foo.gov.au. - foo.com.au. - foo.blah.com. And it would add these all as forwarders to the VPN DNS servers C) Change nothing, close this bug, and mark it as a regression in F21. Remove the "use this connection for only resources on it's network" as that functionality will be broken given this change being merged. D) as belowe from Paul: (In reply to Paul Wouters from comment #13) > We should have an option configurable on a per-network basis with NM that > allows a network to dump all the cache and take over all the DNS with a > global forward. It should not be the default. I think that would require > relative minor changes in the software: > > - Extend NM with this per-network option, including GUI support to set/clear > it > - Extend dnssec-trigger to check for this option when triggered by a VPN > client. > > I believe we could write these patches and submit them upstream to NM and > dnssec-trigger. E) Combine Paul's D suggestion to be automatically enabled if "use connection for this network resources only" is enabled. (Still display the UI elements of course) B would be a pain to implement and network providers won't be thrilled at making such a config. C is a terrible idea, but one none the less. D is good, but would need some SERIOUSLY documentation and alt-text in NM to make sure it's not missed by users. E is the best comporomise: All network configurations would continue working as expected, new connections would work as expected. E is my preffered option.
(In reply to William Brown from comment #14) > > Propagate a domain that is common for all hosts on your private network > > (e.g. private.example.com). > > > > We are open to suggestion on how can this be solved in a better way. > > We have far too many zones for this. The only common element is . If that's true, *you* probably *have to* use the VPN name servers to resolve all internet resources. The easiest way with current software is to let the VPN be the default connection. If you have a *very special* case that you *want* to use the VPN's name servers while directing most traffic through a physical device, you would need a special directive in NetworkManager to do that, a special script to configure unbound or a special configuration directive for the dnssec-trigger-script. I could help you with that and submit another `dnssec.conf` option to dnssec-trigger upstream, if that's what you want. Note that it would later be ported to the NetworkManager plugin when it's ready. You are right that current NetworkManager does that but it's a side effect of its inability to perform split DNS configuration. When you switch to the dnsmasq plugin which already supports split DNS, it will already work correctly (i.e. not how you want it). In fact you are relying on a serious bug and privacy/security issue here which leaks information about non-VPN traffic to the VPN. We discussed this many times with NetworkManager developers. > A) Maintain the current expected behaviour. Use the DNS from that network as > default when you join, even if it's set to "only for that networks > resources". This should never become the default because of the privacy/security noted above as well as others. But it could be made an option. > B) Allow NM or other tool to list a complete set of networks for me > "resources only" that will be translated into forwarders. Perhaps even allow > input of an admin provided XML file definition of these. IE I could put in a > list of > > - foo.edu.au. > - foo.gov.au. > - foo.com.au. > - foo.blah.com. An explicit list of domains is a nice feature request for NetworkManager upstream, I will talk to the NetworkManager developers about it. > C) Change nothing, close this bug, and mark it as a regression in F21. This doesn't seem to become a regression in F21 as unbound/dnssec-trigger will still *not* be run by default. We should be careful about F22, though. > Remove the "use this connection for only resources on it's network" as that > functionality will be broken given this change being merged. Nope. This option works perfectly well with the unbound scripts/plugin as well as with dnsmasq plugin in NetworkManager that has been there for years. You just aren't happy with the automatic split DNS for obvious reasons. But please don't generalize your use case for the reasons stated above. > D) as belowe from Paul: > > (In reply to Paul Wouters from comment #13) > > We should have an option configurable on a per-network basis with NM that > > allows a network to dump all the cache and take over all the DNS with a > > global forward. It should not be the default. I think that would require > > relative minor changes in the software: At first I didn't understand it but it seems to be similar to my offer to try to submit another opt-in dnssec.conf option to force VPN's global DNS servers even if it's not the default connection. > E) Combine Paul's D suggestion to be automatically enabled if "use > connection for this network resources only" is enabled. -1 for already stated reasons. > B would be a pain to implement I believe B will be implemented *anyway* as it's often useful to override NetworkManager's idea of dynamically requested network configuration. It fits NetworkManager workflow perfectly. > D is good, but would need some SERIOUSLY documentation Sure. > and alt-text in NM to make sure it's not missed by users. Once it's implemented in the lower levels, you can file a bug with Gnome for that and fight for it :). > E is the best comporomise: All network configurations would continue working > as expected, new connections would work as expected. I consider E a security bug, albeit a known one and existing for years in NetworkManager, and also exactly contradicting the description of the option.
Changing the summary to reflect the actual request.
I agree with Pavlix that William's variant (E) contradicts meaning of "use connection for this network resources only". If you want to blindly trust network behind VPN then you should uncheck "use connection for this network resources only".
(In reply to Petr Spacek from comment #17) > I agree with Pavlix that William's variant (E) contradicts meaning of "use > connection for this network resources only". If you want to blindly trust > network behind VPN then you should uncheck "use connection for this network > resources only". +1 If you want to use some network only for resources from that network, you should NOT use it for resolving ALL DNS queries. This is just wrong by definition.
True, it may be a risk, but right now it's the only way to guarantee functionality on a VPN. This is a fundamentally difficult problem, and perhaps the way of adding a list of networks to a VPN is the "perfect" solution, but I think you need to consider the balance of security versus usability. If a VPN is something you connect to, you should trust it. If you make users add all their possible zones to a vpn connection, this is very inconvinent. Most users of the network at my work place, would have no way to access the complete list of DNS zones possibly able to resolve to add in this case. I have plenty of other practical reasons why I don't make a VPN the "default" connection when I connect to my work connection. I don't think it correct to complexify vpn connections any more than they are. I would rather warn the user about the implications and allow them to take responsibility.
(In reply to William Brown from comment #19) > True, it may be a risk, but right now it's the only way to guarantee > functionality on a VPN. Please don't generalize. *Any* VPN can be used if you choose it as a default connection. All VPNs except those featuring a multiview on a random number of zones can be used even if you don't. We're talking about a very specific situation here, not about the general case. > If a VPN is something you connect to, you should trust it. If you trust it, then you can use it for all traffic and that already works perfectly. What you're seeking is a very special configuration of not using the VPN for the traffic but using is for DNS. I'm not convinced that this is the best default behavior. It's very easy to find a couple of specific counterexamples to the generalization of your specific setup. What if you for example wanted to connect to a customer's VPN when connected to your network? Is it ok to break your local access, then? I understand you're seeing your own use cases every day but try to think about other users as well. I'm afraid tweaking the system to your needs will require both *using DNS from a non-default-routing connection* and *turning off DNSSEC* (unless DNSSEC multiview is already deployed there). When working on DNSSEC support in Fedora, we don't consider those to be good defaults. But we certainly want to make it possible to configure your system so.
(In reply to Pavel Šimerda (pavlix) from comment #20) > (In reply to William Brown from comment #19) > > True, it may be a risk, but right now it's the only way to guarantee > > functionality on a VPN. > > Please don't generalize. *Any* VPN can be used if you choose it as a default > connection. All VPNs except those featuring a multiview on a random number > of zones can be used even if you don't. We're talking about a very specific > situation here, not about the general case. True it may be, but it's an option that exists in the software. This change makes that option "useless" (The only for resources on network option this is) > > > If a VPN is something you connect to, you should trust it. > > If you trust it, then you can use it for all traffic and that already works > perfectly. What you're seeking is a very special configuration of not using > the VPN for the traffic but using is for DNS. I'm not convinced that this is > the best default behavior. But you don't always want to use it for all traffic. Else the option wouldn't exist ;) > > It's very easy to find a couple of specific counterexamples to the > generalization of your specific setup. What if you for example wanted to > connect to a customer's VPN when connected to your network? Is it ok to > break your local access, then? That's true now. There are lots of examples in both directions. This is why introducing something like unbound by default is such a risky change is because of all the possible networks and scenarios that exist. > > I understand you're seeing your own use cases every day but try to think > about other users as well. I'm afraid tweaking the system to your needs will > require both *using DNS from a non-default-routing connection* and *turning > off DNSSEC* (unless DNSSEC multiview is already deployed there). When > working on DNSSEC support in Fedora, we don't consider those to be good > defaults. But we certainly want to make it possible to configure your system > so. Yes of course: But there seem to be plenty of people (Not yourself) who see their own use case and assume that this change is without flaw or risk: I am making the point that this is no the case. So what then is the outcome of this ticket: How can we make this work?
(In reply to William Brown from comment #21) > True it may be, but it's an option that exists in the software. This change > makes that option "useless" (The only for resources on network option this > is) We already know that *when the list of zones is not available*, the standard split DNS configuration cannot provide you access to the resources on the VPN network unless you either use the VPN for all resources or access the resources via IP address. I don't think the use case for this request needs any further clarification. There are *good reasons* not to just go and switch dnssec-trigger-script to use VPN nameservers instead of the default name servers, see below. > But you don't always want to use it for all traffic. Else the option > wouldn't exist ;) It is a known problem that the option only does what it says when split DNS configuration is enabled (dns=dnsmasq or when unbound being used). In the default configuration, using /etc/resolv.conf, the VPN (especially its nameservers) is being (partially) used to access non-VPN resources. This is a serious privacy leak with potentially bad consequences. Also, while not yet implemented in NetworkManager, the split DNS setup guarantees that you can use resources on multiple distinct VPNs, if the zone lists don't overlap. Also please note that this is a relatively minor issue as you can easily > That's true now. There are lots of examples in both directions. This is why > introducing something like unbound by default is such a risky change is > because of all the possible networks and scenarios that exist. That's exactly why we're *not* introducing unbound by default, yet. We will have the full cycle between Fedora 21 and Fedora 22 releases. It is an important change in networking in Fedora that comes with new possibilities as well as new issues. It has been delayed for years to make NetworkManager's 'dns=dnsmasq' default, so only part of the users actually used it. I think it should have been done years ago and issues would have been known and fixed or worked around but now there's a new motivation to also support DNSSEC which is needed for so many projects. > So what then is the outcome of this ticket: How can we make this work? In my opinion, there should be an option in NetworkManager to select a connection for providing the DNS servers instead of the default connection. The plugin/script could then use this information to pick the right set of DNS servers. NetworkManager developers will certainly have their own ideas and/or improvements.
(In reply to Pavel Šimerda (pavlix) from comment #22) > > So what then is the outcome of this ticket: How can we make this work? > > In my opinion, there should be an option in NetworkManager to select a > connection for providing the DNS servers instead of the default connection. > The plugin/script could then use this information to pick the right set of > DNS servers. NetworkManager developers will certainly have their own ideas > and/or improvements. Plus, it should be presented in the GUI somewhere near the option to use VPN only for local resources.
Workaround: Just wanted to note that it is easy to alter the python script located in /usr/libexec/dnssec-trigger-script to change the DNS logic so that the VPN nameservers are preferred over the default connection name servers.
Created attachment 978292 [details] experimental patch to prefer VPN With this experimental patch (applies to dnssec-trigger SVN trunk) the behavior is as described in the bug report. I still expect the final patch to make it an option, not the only way.
i hope the option will default to OFF if a split tunnel is detecting? (It's fine if the VPN is for all traffic)
(In reply to Paul Wouters from comment #26) > i hope the option will default to OFF if a split tunnel is detecting? (It's > fine if the VPN is for all traffic) +1 It should definitely not be the default behavior.
Fixed in rawhide, built also for F20. Not default behavior, no documentation, just the feature available for testing. http://koji.fedoraproject.org/koji/buildinfo?buildID=605242 How to test: /etc/dnssec.conf: use_vpn_global_forwarders=yes # systemctl restart unbound The purpose of the feature is to allow the administrator to partially mimic the behavior of NetworkManager. It is not generally recommended.
You should be now using F21 for testing DNSSEC features. We'll probably have an update for F20 as well but that's not a priority, switching to F21.
dnssec-trigger-0.12-18.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/dnssec-trigger-0.12-18.fc21
Package dnssec-trigger-0.12-18.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnssec-trigger-0.12-18.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-1279/dnssec-trigger-0.12-18.fc21 then log in and leave karma (feedback).
dnssec-trigger-0.12-19.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/FEDORA-2015-3864/dnssec-trigger-0.12-19.fc22
dnssec-trigger-0.12-19.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/FEDORA-2015-3843/dnssec-trigger-0.12-19.fc21
dnssec-trigger-0.12-19.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
dnssec-trigger-0.12-20.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.