Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Mon, Sep 28, 2020 at 2:44 pm, Simo Sorce <simo@xxxxxxxxxx> wrote:
No, this is wrong, DNS and traffic routing are absolutely disjoint
hitngs, and you cannot assume that DNS ought to work as traffic
routing, because it never did.

Hi Simo,

Apologies for a long reply, but I wanted to try to address at least most of your concerns.

I would say that rather than *assuming* how things work, we're *defining* it. We have to pick some default behavior, and I think splitting DNS is least-likely to subvert user expectations, therefore least-likely to lead to privacy mistakes.

Now, we only have one GUI option here: "use this connection only for resources on its network." If we want to offer the user the choice of whether to split DNS along with routing, well, then we need more than one option, and we're really getting into the weeds and probably exceeding a reasonable complexity limit for an already-complex network configuration dialog. This is a niche use-case IMO -- with the possible exception of managed corporate deployments where our defaults do not matter, more on that below -- and it's much easier to handle this case by letting the user manually specify the DNS server to use for the connection, which will now actually work in F33 with systemd-resolved. Try this in F32 and all the servers you've configured from various network connections all get jumbled together in /etc/resolv.conf, in uncertain order, with only the one that's lucky enough to be first actually used. Behavior changes based on the order that you connect or disconnect your VPNs and DNS winds up going to unexpected places. But in F33, it just works, so you can easily configure your DNS exactly as you please. So if you want your VPN to get all your DNS but only traffic for its own network, you can still do it.

Traditionally you had a locally defined DNS server that would answer
your queries, and for traffic you had routers that would decide where
the traffic go, and there is absolutely no correlation between the two.

Actually from the DNS pov, traditionally, what is called "split DNS" is
almost a capital sin.
In fact the default *should* be to use a VPN DNS *unless* the user
explicitly tells you it doesn't fully trust the VPN and wants to try to
split out the traffic.

That's still the case. All this discussion about split DNS is only relevant to the case where the user checks the box "use this connection only for resources on its network" (or imports a VPN profile that selects that automatically). By default, it's not checked, nothing is split, all DNS and routing goes to the VPN.

Multiple VPNs definitely pose a problem, so a proper interface may
allow the user to define a "primary" VPN so that would be the one where
you send the bulk of DNS traffic.

Yeah, I suspect we have room for improvement there. But regardless, you'll get a sensible result as long as you have no more than one VPN for which "use this connection only for resources on its network" is not checked. As long as there's only one with that box unchecked, it's your primary VPN, and the rest are secondary.

I don't think it would be smart for employees to voluntarily opt-in to
 sending all DNS to their employer anyway...

This statement really needs to be justified at length, in normal
copropate environment the equipment is owned by the company and all DNS
traffic *is* expected to go through the VPN so as not to leak your
queries to the internet directly.

In a normal corporate environment, your machines are managed by the corporation and may (or may not) be subject to Big Brother surveillance, possibly to a much higher degree than just watching your DNS. However closely you're being watched, one thing is certain: the corporation will configure your DNS for you, however it pleases. Our defaults just don't matter, because the corporation will change them. It will decide where your DNS goes and where your traffic goes. If it wants to get all your DNS but not all your traffic, the configuration with systemd-resolved is a little different than it was traditionally, but it's not hard to do.

The case where our defaults really matter is for unmanaged systems, where the corporation is not configuring your defaults, the computer is owned by the end user, and the end user is configuring the VPN but is not an expert in DNS or routing or any network-related topics. I'm firmly convinced that almost nobody in this case would intentionally choose for the corporation to receive DNS but not corresponding traffic, because that can only benefit the corporation. There's really very few conceivable situations where that benefits the user. I can think of only one: you want to resolve an internal domain using the corporate DNS server, but don't have a search domain configured for it. (In that case, the solution is to manually add a search domain.) The much more common case is the corporation finds something it doesn't like in employee's DNS (for a G-rated example, let's say too much time on Facebook) and employee gets in trouble for that.

Please note that we still default to sending *everything* to the corporation, all DNS and all traffic. Only if you check the "use this connection only for resources on its network" box do we then go into split mode, on the assumption that split DNS is likely what the user wants. So the change here is that if you ask for the split, now you actually get a proper split with no DNS leaks. If you don't ask for the split, of course there's not going to be a split.

(In F32, the user would *think* everything is split if selecting this option, but DNS would not be split -- only traffic -- so the corporation would still see your embarrassing DNS queries. Or, depending on connection order, the opposite might occur, the corporation might receive traffic but no DNS at all, breaking internal name resolution.)

I hope that addresses most of your next points, so I'll skip down a few:

 Of course, it's still possible to get the old behavior if you really
want to, but it will now require custom configuration not available via
 GUI,

And this is a big problem, you are trying to enhance privacy in one
direction, but failing to do so in the other. This should be considered
a bug, given all the other reasons you gave for the change.

I'm confused here. My goal is to avoid subverting user expectations by defaulting to sending DNS wherever the traffic goes if the user has configured a split. The biggest risk to privacy is if we fail to adhere to user expectations, right?

I do for my corporate laptop, so I think you have incorrectly assessed
the situation.
I would also want to opt-into sending everytihng on the VPN if it were
a privacy-VPN, there MUST be a button that says "use *only* _this_ VPN
for *all* DNS traffic" if you care about user's privacy.

So focusing only on the case where you have configured a split (because if there's no split, none of this is relevant): we don't have an easy button to let you use one VPN for DNS corresponding to traffic that it doesn't receive. Of course, it's possible to configure that by manually setting the other VPNs to use custom DNS, but it's a very strange case. If you're not routing all traffic through the VPN, then when is it important for privacy that the DNS also goes to that VPN? That's probably not what you really want? Normally, if you are using a VPN for privacy, you want to ensure all DNS goes through it, *except* DNS for internal resources associated with your non-primary VPNs.

  If you're using
a managed system, you're probably surveilled anyway, so better assume
 nothing is safe.

 > * There is no real protocol for sharing internal domains, so
> systemd-resolved cannot know all of them, and resolving some of them
 >   will fail or receive unexpected resolution results (probably
 >   observable for some jboss.org subdomains for Red Hatters, but I
 > don't
 >   work in that area, so I don't have a good example at hand).

Yes, that's true. And there's not currently any good solution to that
 without resorting to the command line.

And this is a bug.

Yeah, this is a fair complaint.

Of course, this problem is avoidable by unchecking "use this connection only for resources on its network" if you use only one VPN. And failing that: at least the situation is not worse than it was before.

Michael

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux