Comment 67 for bug 1754671

Pavel, I'll admit to not 100% following what you've suggested, so please excuse me if I've horribly miss-understood. I disagree with the assertion that "There is no such think as sending all traffic across VPN". The parent interface's adapter will have a local route mainly so you can get to the gateway, as well as a route for vpn endpoint you need to push traffic at however, there are some mitigating circumstances that forcing split-dns, so that the DNS on the VPN is ONLY serving the search spaces pushed, is actually exactly the opposite of what a user likely wants and/or causes some rather broken behavior.

- VPNs can, and often do, have IP space overlap issues. So if the parent interface's network you are on happens to be in the 10.0.0.0/255.255.252.0 (gateway 10.0.0.1, DNS server 10.0.0.2 & 10.0.0.3) ip range, and the VPN uses 10.0.1.0/255.255.255.0, you can end up in some very screwed up situation. This is actually taken from a real world scenario (which is why I learned of the change to default to split DNS at all). If you are routing all traffic over the VPN you now have lost access to the two parent interface's DNS servers, and with split DNS you now have *NO* DNS access at all. As it currently stands the only way to fix this is to either manually edit /etc/resolv.conf or to restart NM without dnsmasq.

- DNS is not equal at all locations, which your assumption about split DNS I think assumes. DNS zones mean that something that resolves externally one way, may resolve completely differently (and potentially). example.com, to an external resolver may go to a coloed and public instance, while the same dns entry from an internal dns server may not. Assuming the VPN only pushes a search of internal.example.com, but doesn't push a search for example.com (making the assumption that people will just type it), the internal site is now unreachable. Keeping in mind I'm talking about VPNs, and those are typically used in more corporate environments where you are dealing with corporate IT departments.

- In a more casual environment, lets say a hotel, part of the reasons to use a VPN is because the user EXPLICITLY doesn't trust anything about the network they are on, up to and including the DNS servers. The user, if they are routing everything, is pretty likely to trust the DNS servers on the far side of the VPN. There's actually plenty of security concerns there, and I for one would have assumed that if I'm routing all my traffic over the VPN, my DNS traffic was as well (meaning I wouldn't have been relying on, or trusting, DNS servers I don't trust).

These are the three issues I'm most concerned about keeping split-dns as the default without choice. There are situations where I want split-dns, it's great and it's a fantastic feature, but in the case of a vpn that's intending to route all traffic, I'd argue the expected case is that all traffic, including all DNS queries, go over the vpn and it is not split.