On Mon, Sep 28, 2020 at 2:44 pm, Simo Sorce <s...@redhat.com> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
