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 (joh...@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: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
