Comment 35 for bug 1624317

I dup'ed another bug onto this, as I think they are essentially the same.

While Martin worked on the domain-restricted cases the reporter and others outlined that this is not what this bug is about.

TL;DR:
- anything (like vpn) provides new DNS servers on an extra link
  - lets call them "internal" and "external" sources of DNS info
- systemd-resolved asks ALL local interfaces concurrently and takes the fastest answer
- now we have two breaking use cases:
  - if "internal" and "external" are intentionally configured to report differently (override a DNS name to internal host) you can no more rely on getting the internal resolution
  - by asking "external" even if "internal" holds an answer is a dns leak as in [1]

At least for the VPN cases - and most here seem to be that - what we would need is a way to "disable" the DNS resolving on the original interface.

From man systemd-resolved:
Multi-label names are routed to all local interfaces that have a DNS sever configured, plus the
globally configured DNS server if there is one. [...]

If lookups are routed to multiple interfaces, the first successful response is returned (thus
effectively merging the lookup zones on all matching interfaces). If the lookup failed on all
interfaces, the last failing response is returned.

From the bug I dupped we have the output of
$ systemd-resolve --status
(There is also tcpdump data there)
Both confirms that is lists all links and their DNS
Link 4 (tun0)
      Current Scopes: DNS
[...]
         DNS Servers: 209.222.18.222
                      209.222.18.218
Link 3 (wlp3s0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
[...]
         DNS Servers: 192.168.0.1

Combined with the concurrent-quere-prefer-first behavior above that might be the root cause for all or most of the people chiming in here.

[1]: https://www.dnsleaktest.com/