On Mon, 2020-09-28 at 10:51 -0500, Michael Catanzaro wrote: > I don't think my description is misleading.... > > On Mon, Sep 28, 2020 at 5:28 pm, Florian Weimer <fwei...@redhat.com> > wrote: > > * The change disables protection mechanisms built into corporate VPNs > > that require them to observe all DNS traffic. Now this may sound > > rather weak as far as countermeasures go, but DNS-based mechanisms > > are > > the only thing you have got if you do not enforce a client-side > > approach (ugh, no thanks), or disable split tunneling (i.e., default > > route over the VPN; frequently not possible with current VPN usage > > levels and virtual company meetings over video link). > > Correct. If you want to observe all DNS traffic, that is no longer > possible by default unless you also handle routing all traffic. I'd > argue that's a good change. From a system design perspective, that's > just how DNS ought to work.
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. 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. 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. > 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. > there's little benefit to > the employee, and a lot of downside. Sorry, but this is quite debatable, and entirely depends on the relationship between employer and employee among other things. Nothing you can assert or assume. > Importantly, if you're looking in > your network settings and you see a checkbox that says "Use this > connection only for resources on its network," a reasonable user > *expects* that the connection will *really* only be used for resources > on its network, not that it will be used for everything except DNS, This is in fact a good indication of the intention a user have. I use in some context and not others. > which randomly goes to who knows where depending on what else you're > connected to. Our design must try to avoid this failure case: "Sadly > for Distrustful Denise, her employer discovers that she has been making > some embarrassing DNS requests that she had expected to go through > public-vpn.example.com instead." This is where you should have a "This is my primary VPN" option, which means all DNS traffic goes there when it is active. > 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. > and nobody really wants to opt-in to that behavior, so it's not > likely to be used except in managed corporate systems. 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. > 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. my 2c, Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ 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
