On Tuesday, September 29, 2020 6:41:12 AM MST Lennart Poettering wrote: > On Di, 29.09.20 04:03, John M. Harris Jr (johnmh@xxxxxxxxxxxxx) 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. > > 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. There seems to be some confusion in this thread as to how exactly that works. It seems that the individual pushing this change is under the assumption that this implements 'Split DNS', that only requests for VPN resources are queried from the VPN's DNS server(s). > 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) Well, we have the routing information, unless the VPN is one flat network. However, routing has absolutely nothing to do with DNS. Routing is a layer below, and is most likely required for your DNS queries to actually get to the DNS server(s) inside the VPN. > 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. > > 3. In others routing all DNS traffic via local DNS and nothing via VPN > might be workable option. In others this would be wrong. > > 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". This seems to be the part where the Change Owner is confused as to how this works, which is concerning at best. We need to be very careful when changing functionality that is so essential to the way Fedora systems use network resources, this is a pretty big change in functionality, and doesn't provide 'Split DNS', the issue the Change was originally created to solve. -- John M. Harris, Jr. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
