resolved: beef up domain routing #11050

poettering · 2018-12-04T17:04:59Z

grooverdan

Thanks. Looks good to solve issues.

As I understand it, the Default [DNS] Route being 'yes' looks like an explicit '~.' and a setting to treat DNS Domains as route prefixes only, and not search domains. Was the new setting to preserve the existing behaviour in some way? Is there another function it serves?

Are there test cases for this complex interaction?

Much appreciate the fix.

grooverdan · 2018-12-05T00:07:19Z

man/systemd-resolved.service.xml

+    <itemizedlist>
+      <listitem><para>If a name to look up matches any of the configured search or route-only domains of any link (or
+      the globally configured DNS settings), the "best matching" search/route-only domain is determined: the matching
+      one with the most labels. The query is then sent to all DNS servers of any links or the globally configured DNS


"If no answer, the query is then sent.."

oh, this is actually not what is meant here. We first determine the "best matching" domain, and then look for all links that have this "best matching" domain among their configured search domains. The query is then sent to all of them in parallel. This might be a single link or multiple, if the admin specified the same domains on two interfaces.

I will reword this in the man page

man/systemd-resolved.service.xml

src/resolve/resolved-dns-scope.c

grooverdan · 2018-12-05T08:31:26Z

tested on fc29 - resolves #10830 #9825 for me.

yuwata · 2018-12-05T08:58:17Z

networkd-test.py fails...

poettering · 2018-12-12T09:27:44Z

As I understand it, the Default [DNS] Route being 'yes' looks like an explicit '~.' and a setting to treat DNS Domains as route prefixes only, and not search domains. Was the new setting to preserve the existing behaviour in some way? Is there another function it serves?

Not sure I grok fully what you are trying to day. But there are three levels now:

If you define ~. among the domains of an interface it will preferably get "default" traffic
Interfaces lacking ~. and with the default of DefaultRoute=no left in place will get "default" traffic if no other interface wants it preferably.
Interfaces lacking ~. and with DefaultRoute=yes will never get "default" traffic.

As tests there's test/networkd-test.py, but the routing tests are minimal, and don't cover the three levels of "default route" currently.

poettering · 2018-12-12T09:48:04Z

I force pushed a new version, rebase on current git, with the CI tests (hopefully) fixed. Also fixed the typos and stuff @grooverdan's discovered. PTAL

grooverdan · 2018-12-12T09:57:17Z

I've been running this branch of systemd resolved on my laptop for the last 8 days with the correct domain routing behaviour observed switching between wired and wireless networks, with and without vpn, every few days. Except for occasionally needing to 'resolvectl revert {previous link}' its been working well.

evverx · 2018-12-15T14:49:55Z

Travis CI failed due to #11170.

keszybz

Some minor comments and questions... But some rework is needed.

man/systemd-resolved.service.xml

src/resolve/resolved-dns-scope.c

src/resolve/resolved-link.c

man/systemd.network.xml

This was forgotten when DoT was added.

The _INVALID and _MAX enum fields should always use the full name of thenum.

…m Link

Fixes: systemd#10830 systemd#9825 systemd#9472

Previously, we'd return DNS_SCOPE_MAYBE for all domain lookups matching LLMNR or mDNS. Let's upgrade this to DNS_SCOPE_YES, to make the binding stronger. The effect of this is that even if "local" is defined as routing domain on some iface, we'll still lookup domains in local via mDNS — if mDNS is turned on. This should not be limiting, as people who don't want such lookups should turn off mDNS altogether, as it is useless if nothing is routed to it. This also has the nice benefit that mDNS/LLMR continue to work if people use "~." as routing domain on some interface. Similar for LLMNR and single label names. Similar also for the link local IPv4 and IPv6 reverse lookups. Fixes: systemd#10125

…as_route_only_domains() The function dns_server_limited_domains() was very strange as it enumerate the domains associated with a DnsScope object to determine whether any "route-only" domains, but did so as a function associated with a DnsServer object. Let's clear this up, and replace it by a function associated with a DnsScope instead. This makes more sense philosphically and allows us to reduce the loops through which we need to jump to determine whether a scope is suitable for default routing a bit.

…s default route Previously, we'd use a link as "default" route depending on whether there are route-only domains defined on it or not. (If there are, it would not be used as default route, if there aren't it would.) Let's make this explicit and add a link variable controlling this. The variable is not changeable from the outside yet, but subsequent commits are supposed to add that. Note that making this configurable adds a certain amount of redundancy, as there are now two ways to ensure a link does not receive "default" lookup (i.e. DNS queries matching no configured route): 1. By ensuring that at least one other link configures a route on it (for example by add "." to its search list) 2. By setting this new boolean to false. But this is exactly what is intended with this patch: that there is an explicit way to configure on the link itself whether it receives 'default' traffic, rather than require this to be configured on other links. The variable added is a tri-state: if true, the link is suitable for recieving "default" traffic. If false, the link is not suitable for it. If unset (i.e. negative) the original logic of "has this route-only routes" is used, to ensure compatibility with the status quo ante.

…boolean

This simply reads from networkd's state files whether a link shall be used as DNS default route.

Also, do some minor updating.

…e detail

poettering · 2018-12-21T11:16:10Z

I force pushed a new version now. Only changes are the ones @keszybz pointed out above, modulo the ones I commented out above. I also rebased, in the hope the CI goes all green. PTAL!

poettering · 2018-12-21T17:03:54Z

OK, let's merge this. The changes I made were mostly in docs after all, and @keszybz liked it pretty much, the CI is all green, @grooverdan tested it successfully.

nathan-wmrln · 2019-03-01T00:56:03Z

There's a special case that's been biting me: I have an interface that looks like this:

Link 8 (tun0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 172.31.0.2
          DNS Domain: ~.

Everything works fine when /etc/resolv.conf is symlinked to /run/systemd/resolve/stub-resolv.conf. But in /run/systemd/resolve/resolv.conf, the nameservers that I don't want to use, still appear, in an order that seems nondeterministic:

nameserver x.y.z.a
nameserver y.z.a.b
nameserver 172.31.0.2

It would be best if it could either ensure that 172.31.0.2 is always listed first in such a special case, or, better yet to avoid DNS leaks over a VPN, ensure that it's the only server listed. Is that case dealt with by this PR?

tomtastic · 2019-04-23T17:07:22Z

I have the same issue as @nathan-wmrln using systemd 240. With /etc/systemd/network/all.network :

[DHCP]
UseDNS=false

works for /run/systemd/resolve/stub-resolv.conf, but not for /run/resolvconf/resolv.conf

poettering added the resolve label Dec 4, 2018

poettering force-pushed the resolved-domain-route branch from 382cb6b to be7221d Compare December 4, 2018 17:53

arno01 mentioned this pull request Dec 4, 2018

After connected to VPN, systemd-resolve still use ISP's DNS server( which was polluted because of regulation ) #6076

Closed

grooverdan reviewed Dec 5, 2018

View reviewed changes

yuwata added the ci-fails/needs-rework 🔥 Please rework this, the CI noticed an issue with the PR label Dec 5, 2018

poettering force-pushed the resolved-domain-route branch from be7221d to 770e546 Compare December 12, 2018 09:46

poettering force-pushed the resolved-domain-route branch from 770e546 to 0264ce6 Compare December 12, 2018 09:48

poettering removed the ci-fails/needs-rework 🔥 Please rework this, the CI noticed an issue with the PR label Dec 12, 2018

poettering force-pushed the resolved-domain-route branch from 0264ce6 to fb0ff59 Compare December 15, 2018 11:17

poettering added this to the v240 milestone Dec 16, 2018

poettering force-pushed the resolved-domain-route branch 2 times, most recently from b690b08 to bb1ede3 Compare December 18, 2018 10:35

This was referenced Dec 20, 2018

[systemd-resolved] allow for domain-specific upstream DNS #9944

Closed

support additional unicast DNS scopes, on top of the primary and the per-link ones #5573

Closed

keszybz requested changes Dec 20, 2018

View reviewed changes

keszybz added the reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks label Dec 20, 2018

poettering added 4 commits December 21, 2018 11:04

resolved: use structured initialization for DnsScope

9a1bbc6

resolved: check dns_over_tls_mode in link_needs_save()

dc2bc98

This was forgotten when DoT was added.

resolved: rename_DNS_SCOPE_INVALID → _DNS_SCOPE_MATCH_INVALID

2bfdd6d

The _INVALID and _MAX enum fields should always use the full name of thenum.

resolved: add comment, explaining when Scope variables are copied fro…

89307df

…m Link

poettering added 13 commits December 21, 2018 11:04

resolved: rework how we determine which scope to send a query to

a97a3b2

Fixes: systemd#10830 systemd#9825 systemd#9472

resolved: add bus API to set per-link "default route" boolean

7767379

resolvectl: minor whitespace fix

efe55c8

resolvectl: add support for reading/writing per-link 'default-route' …

f2fd3cd

…boolean

networkd: small simplification

0945197

networkd: permit DNS "DefaultRoute" configuration in .network files

7ece6f5

sd-network: add new API sd_network_link_get_dns_default_route()

c629354

This simply reads from networkd's state files whether a link shall be used as DNS default route.

resolved: read DNS default route option from networkd

fdb4d31

man: split long section in systemd-resolved.service man page into three

396c716

Also, do some minor updating.

man: document new systemd-resolved.service(8) routing features in mor…

2e88625

…e detail

poettering force-pushed the resolved-domain-route branch from bb1ede3 to 2e88625 Compare December 21, 2018 11:15

poettering removed the reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks label Dec 21, 2018

cdown mentioned this pull request Dec 21, 2018

NEWS and build system bump for 240 #11239

Merged

poettering merged commit 44f52cc into systemd:master Dec 21, 2018

piotr-dobrogost mentioned this pull request Jan 3, 2019

Support new "DNSDefaultRoute" option? jonathanio/update-systemd-resolved#60

Closed

Uh oh!

resolved: beef up domain routing #11050

resolved: beef up domain routing #11050

Uh oh!

Conversation

poettering commented Dec 4, 2018

Uh oh!

grooverdan left a comment

Choose a reason for hiding this comment

Uh oh!

grooverdan Dec 5, 2018

Choose a reason for hiding this comment

Uh oh!

poettering Dec 12, 2018

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

grooverdan commented Dec 5, 2018

Uh oh!

yuwata commented Dec 5, 2018

Uh oh!

poettering commented Dec 12, 2018

Uh oh!

poettering commented Dec 12, 2018

Uh oh!

grooverdan commented Dec 12, 2018

Uh oh!

evverx commented Dec 15, 2018

Uh oh!

keszybz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

poettering commented Dec 21, 2018

Uh oh!

poettering commented Dec 21, 2018

Uh oh!

nathan-wmrln commented Mar 1, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tomtastic commented Apr 23, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

nathan-wmrln commented Mar 1, 2019 •

edited

Loading

tomtastic commented Apr 23, 2019 •

edited

Loading