On 9/29/20 10:01 AM, Lennart Poettering wrote: > On Mo, 28.09.20 23:37, John M. Harris Jr (joh...@splentity.com) wrote: > >>> Configure "." as "routing domain" on a specific iface and the lookups >>> wil go there preferably. If you put that on your VPN iface this means >>> DNS traffic goes there preferably. If you put that ont he main iface this >>> means DNS traffic goes there preferably. >> >> Is that a NetworkManager setting or a systemd-resolved setting? Is that going >> to be exposed in the GUI, or is it something that gets hidden away? > > I am not an NM guy, but I think they expose this these days. I can > tell you definitely though that this is easily accessible via > "resolvectl domain <iface>" from the command line and from .network > networkd configuration files. > >> How does systemd-resolved figure out what domains "should" be sent to a given >> connection's DNS server without some arcane incantation from the systemd >> docs? > > As mentioned elsewhere: > > 1) Search domains are implicitly routing domains: if an interface has > "redhat.com" as search domain we also use that as routing domain, > i.e. all *.redhat.com lookups will go to this interface and not to > others.
This is the same algorithm dnssec-trigger uses for this purpose. Because nothing better is there. dnssec-trigger ignores search domain in user configuration, using it exclusively to "route" domain requests to correct servers. Anyway, there exist at least three implementations able to do split DNS scenario, systemd-resolved, dnsmasq and dnssec-trigger+unbound. For some reason, there is no common layer of configuring it inside Network Manager. I think routed domains should be configured there and any split DNS provider should get it from there. No VPN should put it to specific implementation, be it systemd or unbound. > > 2) If neither search domains nor routing domains are configured on any > interface for a domain, lookups are routed to all interfaces in > parallel, and the first positive and last negative answer is used. This is very tragic way of doing it for privacy. You just shout out every request you have to all parties without any priority. This is not how it was done without systemd-resolved. This is much worse. Please reconsider it. If no split view configuration known, all names should be handled to VPN. If more of them, use priority of NM connection or manual configuration. Allow local override. As was said, search is done used for something else by default. Please don't force me share my porn sites with both employer AND ISP. Just one of them is enough. Wait for timeout from the first one before trying next one. > > i.e. focus is primarily on "let's make DNS work" and "let's make the > best of the little information we traditionally have", and any > further, more complex routing requires additional configuration in NM, > networkd or directly with resolvectl commands. Use any information provided by network administrators, but allow local overrides. But stay secure at the same time. Put complexity to network configuration, resolved should fetch it from there. > > Lennart > > -- > Lennart Poettering, Berlin > _______________________________________________ > 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 > Petr -- 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
