Hi Lennart,
more below...
On 9/29/20 3:41 PM, Lennart Poettering wrote:
On Di, 29.09.20 04:03, John M. Harris Jr (johnmh(a)splentity.com)
wrote:
>> Search domains on VPNs are an indicator that these domains are handled
>> by the VPN, that's why we use them also as routing domains. But this
>> doesn't mean it's the *only* routing domains we use. We use the ones
>> you configure, primarily. But since the concept didn't previously exist
>> we make the best from what we have.
>
> If you really must send DNS queries to both (which defeats the purpose of
> 'Split DNS'), then it may be better to just use the DNS server of the VPN
when
> connected to VPN, then only check the LAN interface when the response is
> NXDOMAIN.
As mentioned in this thread already: this policy makes sense for some
cases but not for others.
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.
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.
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?
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.
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?
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?
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.
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.
Lennart
--
Lennart Poettering, Berlin
Petr, Brno
--
Petr Menšík
Software Engineer
Red Hat,
http://www.redhat.com/
email: pemensik(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB