On 9/29/20 5:21 PM, Lennart Poettering wrote:
On Di, 29.09.20 16:03, Petr Menšík (pemensik(a)redhat.com) wrote:
>> For example, if I have my laptop in my home wifi, connected to RH VPN,
>> then there are some names resolvable only via the local
>> DNS. Specifically: my router's, my printer's and my NAS' address.
And
>> there are other names only resolvable via RH VPN. systemd-resolved for
>> the first time gives me a chance for this to just work: it will send
>> requests to both the RH DNS servers and the local ones, and uses the
>> first successful reply, or the last failed reply. And that's quite
>> frankly awesome, because that *never* worked before.
> Would you please try dnssec-trigger? It does exactly this thing. Unlike
> resolved, it can do that also with DNSSEC support on client side. But it
> is not system default.
Hmm? resolved can do DNSSEC too, as mentioned. DNSSEC support is
opt-in though.
> So no, that is not as fresh as you say. Just have to specify subdomains,
> that should be sent to specific server. Not just trying anyone that
> works. Mind my privacy, not everyone has to know what am I
> resolving.
I move my laptop around, I want something that just works. And I am
pretty sure that's the same for Fedora: a DNSSEC implementation that
is opt-out but requires manual config is a no-go.
No-one demands 100% working
validation. We just need 100% working DNSSEC
passthru via resolved, so proper validators can ensure results. There
are problems with DNSSEC. Most of them have known solutions. Just
because your café and modem vendor haven't use any of them.
DNSSEC blocking resolver on fully DNSSEC aware network in year 2020 is
NO-GO to me. It is simple, just don't stand in the way.
>> So sending the requests to all available DNS servers in absence of
>> better routing info is a great enabler: it makes DNS "just work" for
>> many cases, including my own, and I doubt it's a particularly exotic
>> one.
>
> It takes privacy from you and make it much worse. Just because it does
> 'just work'. Wouldn't it make sense to let corporate admins specify,
> what should be routed there? Do you know enterprise VPN, which is
> configured by BFU?
It provides the same privacy guarantees as your solution — as long as
you tell it the routing domains. The only difference: if you don't
tell it anything resolved's behaviour "just works", while your
solution means things do not just work.
It "works", but provides the
other party whole information about what I
visit. Did you know this was the reason for invention of DNS over TLS
and DNS over HTTPS? Even with such encrypted channel, you would leak it
out. If that's the price for "I do not know how but it works", then I
say no, thank you.
It it does not know, you can find a way to make it work. When it works
and leaks, you just won't know.
You know that meme, "It's not DNS. There's no way it's DNS. It was
DNS"?
"It's not systemd. There's no way it's systemd. It was
systemd"? Ever heard this version?
I am pretty sure we shouldn't adopt defaults that break for the
common cases out-of-the-box. Hence, in absence of more explicit
routing info I am very sure "just works" is better than "just fails".
I have no problem with proper autoconfiguration. Throwing queries to
every connection I have is plain wrong and always was. That's the reason
why others let it fail in this case.
Yes, the logic does potentially allow more than you#d want onto some
interfaces, but I don't think a (fake?) sense of "privacy" is a good
excuse for "let's ship something that cannot work by default".>
Yes, I too would prefer if my regular, non-RH DNS traffic never goes
to RH servers while I am in the VPN, and I can easily configure things
that way. But if I am pretty sure the majority of people probably put
more emphasis "please please work" than on "i'd rather have not
working DNS than have DNS queries end up on RH's DNS servers".But you omit easy
configuration on RH VPN server, which would just fix
it. Way to autoconfigure the
service without special configuration done
by mere mortal.
>> Key, take-away here:
>>
>> 1. Ideally we'd just route company DNS traffic to VPN, and everything
>> else to local LAN DNS. But that requires explicit routing info to
>> be configured, we cannot auto-detect this info (beyond some minor
>> inference from the search domains)
> Let company configure it via VPN, allow local override for power
> users.
VPNs generally do not propagate domain routing info. They do provide
search domain info, which — as mentioned — we infer routing info
from. And yes, we of course allow local override.
So: check and check? (to the level this is possible)
>> 2. In some cases hence routing all DNS traffic via VPN and nothing via
>> local might be a workable option. In others this would be
>> wrong.
>
> Can you please be more specific? Example we can argue about?
> _gateway is just bare name, it would make sense to send it to LAN.
> Anything else?
This is what the person I replied to asked for: if VPN is up send all
DNS traffic to VPN, none to local DNS server.
>> 3. In others routing all DNS traffic via local DNS and nothing via VPN
>> might be workable option. In others this would be wrong.
> Never heard about this. Can you provide an example, where is this
> configuration desired? Is there public product or company, that
> configures it service like this? Do they offer DNS server in
> DHCP/autoconfiguration, when they do not want it to be used?
You appear to one of those who wants that, i.e. no have DNS traffic
end up at RH that shouldn't go there if you are in the VPN.
What this boils down to: there are primarily two usecases for VPN I see:
1. employee talks to company VPN to access very specific servers. For
cases like this ideally only company DNS traffic goes to VPN and
nothing else. i.e. porn domain lookups only go to local LAN DNS.
2. user uses public VPN services such as mozilla VPN or Private
Internet Access or a similar service to obstruct the view on what
they are doing to the local network. In this case all DNS traffic
should go to VPN and nothing to local LAN DNS.
Both usecases are equally valid and probably equally popular. We can't
guess what is right.
In the first case the local LAN is more "trusted" if you so will than
the company VPN: pornsite DNS traffic should go to LAN, but not to
VPN. In the latter case the local LAN is less trusted than then used
VPN: pornsite DNS traffic should go to VPN, but never to LAN.
Sure, we have agreement at least. Because we miss way to know which is
the kind, use configuration from VPN or local network to choose. I think
case 2. is the legacy way. If we have no hint from service
configuration, choose the most compatible. Make that choose predictable,
secure and well documented.
>> 4. In all cases where we can't do #1 because we lack the info, and
>> don't know whether to do #2 or #3 because it depends on the type of
>> VPN use, then sending to everything in parallel and taking the
>> first positive reply and the last negative one is the best chance
>> to make things "just work".
>
> Then work on getting the info. If you don't know which variant, choose
> the same as without resolved. That usually would be #2, right? If that
> VPN specified server and it has higher priority, route there. Use any
> place default route is sent to.
Well, except that the info is not provided via openvpn and similar
solutions. I can't make it up from thin air.
It is provided by DHCP.
IP4.DOMAIN[1]:
redhat.com
But I really want to access servers inside the RH VPN and my local
router/printer/NAS at the same time, so I am totally happy that with
resolved this now *just works* even if RH's VPN doesn't tell us
anything about routing domains.
I work for Red Hat too as you may have noticed.
Because we made sure
with dnssec-trigger it tells us to route
redhat.com via VPN. So like
you, I can access local resources in my home network and private
redhat.com hosts at the same configuration. It works automagically
because we requested it. We did not request
jboss.com and that's
missing. Surprise?
Wonders wonders, no resolved involved, just unbound+dnssec-trigger.
Might not be under active development, but still works to some extent.
>> Anyway, I think I am repeating myself here.
> Sure, you repeat yourself. But turn the deaf ear to arguments of others.
> Please use smart defaults, only when they don't endanger user's privacy
> nor security.
I don't think what you are saying is congruent. On one hand you want
that VPNs do not get all DNS traffic apparently, on the other you say
it should have preference over the LAN DNS in all cases if it is
configured? So what is it now?
Make VPN administrator responsible. Do not invent
behaviour, use what
was most likely intended by network provider. Document how to create
working configurations instead of trying to workaround bugs of others.
DNS standards have a story about it and they learned it hard way. One of
reasons DNS is complicated today. Learn from their mistakes.
Anyway, I still believe that making things just work is the best
option, and buying vague "privacy" by "it's ok if it doesn't
work" is
a shitty deal.
Depends what do you trade for. My privacy expectation is simple:
what I
do is not seen by anyone I wouldn't allow. Meaning my browsing history
does just one way with defined exceptions.
Lennart
--
Lennart Poettering, Berlin
--
Petr Menšík
Software Engineer
Red Hat,
http://www.redhat.com/
email: pemensik(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB