GNOME Bugzilla – Bug 772343
resolved dns setup fails with recent systemd
Last modified: 2016-10-14 06:52:47 UTC
Recent systemd git is a lot more specific about what routing domains are, which conflicts with how dns/resolved currently sets up the links. Typically there are no search entries in the IPconfig, but there is a list of domains which means dns/resolved sets the latter list as the routing domains. Which in turn means resolved thinks it can only resolve ip's on those domains with DNS.
Created attachment 336766 [details] [review] dns/resolved: Adjust link domain settings Make link domain settings more conventional. If an IP Config only has no search entries, use domains for search instead otherwise ignore domains. Also on connections which are never the default, setup the search/domains as routing-only meaning that only dns queries for those domains will be done on this link. Prevents quering DNS information for on-vpn host with other namservers and using the VPN DNS server for host not on the VPN. This is also fixes issues with a recent change in systemd-resolved where links with a routing domain will only be used for those domains, which meant that the previous strategry with a typical ip configuration (no search only domains) resulted in no usable name resolution. Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
lgtm, but doesn't follow the coding style: - wrong double-tabs in add_domain() - needs space between function name and parenthesis ("nm_ip4_config_get_num_searches(config)", "add_domain(do..."). - indention after linebreak must be done with spaces (https://www.emacswiki.org/emacs/SmartTabs)
static void +add_domain(GVariantBuilder *domains, + const gchar *domain, + gboolean never_default) +{ + /* If this link is never the default (e.g. only used for resources on this + * network) add a routing domain. */ + g_variant_builder_add (domains, "(sb)", domain, !never_default); It seems to me that the code does the opposite thing of what the comment says (it adds a routing domain if the link is not never-default, i.e. has a default route). When using dnsmasq currently we do split DNS only for VPNs, which means that the VPN upstream server will be used only for queries ending in the supplied domain; but at the same time we add the domain to the resolv.conf search list, and thus the domain will be appended to unqualified names. For non-VPN connections we forward all queries to the upstream DNS server. Also, we don't consider at all the never-default flag (but bug 746422 suggests to do so). If I understand correctly, with resolved we are now always using split DNS, but in a different way, since the domain associated with a link is the preferred one in case of match, but resolved will broadcast to all interfaces in case of no match. Also, the domain will be appended automatically only for connections with the default route. Correct? Since the underlying daemon uses a different paradigm, I think it's fine to have a behavior different from the existing one.
(In reply to Beniamino Galvani from comment #3) > static void > +add_domain(GVariantBuilder *domains, > + const gchar *domain, > + gboolean never_default) > +{ > + /* If this link is never the default (e.g. only used for > resources on this > + * network) add a routing domain. */ > + g_variant_builder_add (domains, "(sb)", domain, > !never_default); > > It seems to me that the code does the opposite thing of what the > comment says (it adds a routing domain if the link is not > never-default, i.e. has a default route). Ugh yes, i streamlined the code a bit before submitting but apparently failed to test (was in a hury as the train station came up). sorry about that, will attach a new patch. > When using dnsmasq currently we do split DNS only for VPNs, which > means that the VPN upstream server will be used only for queries > ending in the supplied domain; but at the same time we add the domain > to the resolv.conf search list, and thus the domain will be appended > to unqualified names. For non-VPN connections we forward all queries > to the upstream DNS server. Also, we don't consider at all the > never-default flag (but bug 746422 suggests to do so). > > If I understand correctly, with resolved we are now always using split > DNS, but in a different way, since the domain associated with a link > is the preferred one in case of match, but resolved will broadcast to > all interfaces in case of no match. Also, the domain will be appended > automatically only for connections with the default route. Correct? No, the search domains will be appended for single-label names on per link basis and only resolved on links that have said domain. Also multi-label names ending in a search domain will only be resolved on links with said search domain. For links with routing-only domains, the dns server on those links are only used for the given multi-label names ending in one of the routing domain. This means that when using a VPN connection configured to only be there for resources on that link and domain vpn, the name badger.vpn will be resolved via the VPN dns servers (but no others) while badger will only be resolved on the systems other nameservers (e.g. local lan). Which means services used on the vlan aren't leaked to nameservers on the machines other networks and vice versa. > Since the underlying daemon uses a different paradigm, I think it's > fine to have a behavior different from the existing one.
Created attachment 337005 [details] [review] dns/resolved: Adjust link domain settings Make link domain settings more conventional. If an IP Config only has no search entries, use domains for search instead otherwise ignore domains. Also on connections which are never the default, setup the search/domains as routing-only meaning that only dns queries for those domains will be done on this link. Prevents quering DNS information for on-vpn host with other namservers and using the VPN DNS server for host not on the VPN. This is also fixes issues with a recent change in systemd-resolved where links with a routing domain will only be used for those domains, which meant that the previous strategry with a typical ip configuration (no search only domains) resulted in no usable name resolution. Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Created attachment 337051 [details] [review] Resubmit, this time with the actual tsted change, gah..
(In reply to Sjoerd Simons from comment #6) > Created attachment 337051 [details] [review] [review] > Resubmit, this time with the actual tsted change, gah.. » » add_domain(domains,·nm_ip4_config_get_search·(config,·i), » » » » ···nm_ip4_config_get_never_default·(config)); On the second line tabs must be used to indent to the beginning of 'add_domain', and the rest should be aligned with spaces: » » add_domain(domains,·nm_ip4_config_get_search·(config,·i), » » ···········nm_ip4_config_get_never_default·(config)); The same for domains and IPv6 searches/domains. The rest LGTM.
Created attachment 337665 [details] [review] dns/resolved: Adjust link domain settings Make link domain settings more conventional. If an IP Config only has no search entries, use domains for search instead otherwise ignore domains. Also on connections which are never the default, setup the search/domains as routing-only meaning that only dns queries for those domains will be done on this link. Prevents quering DNS information for on-vpn host with other namservers and using the VPN DNS server for host not on the VPN. This is also fixes issues with a recent change in systemd-resolved where links with a routing domain will only be used for those domains, which meant that the previous strategry with a typical ip configuration (no search only domains) resulted in no usable name resolution. Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
patch v3 is identical to v2. Anyway, merged: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c4864ba63f4a13e9938a978787490005f5ba48fb
unless git bz is playing tricks on me v3 should have the identation changed :). Thanks for committing!