[Bug 1714803] Re: Search list in resolv.conf breaks resolving for that domain

Wed Oct 11 19:14:45 UTC 2017

On 11 October 2017 at 15:25, Matthias Fratz <1714803 at bugs.launchpad.net> wrote:
> Tried that, and it started using the DHCP-provided search path (yay!).
>
> Setting the search path in NetworkManager (which is responsible for the
> interface in question) works, ie. honors the search path and doesn't
> break resolving for those domains, with both single and multiple search
> paths:
>
> [ipv4]
> dns-search=disy.inf.uni-konstanz.de;inf.uni-konstanz.de;uni-konstanz.de
> method=auto
>
> [ipv6]
> addr-gen-mode=stable-privacy
> dns-search=disy.inf.uni-konstanz.de;inf.uni-konstanz.de;uni-konstanz.de
> method=auto
>
> Having to do this for each connection and for both IPv4 and IPv6 sucks,
> but it's better than not having a search path.
>
>
> Trying to set the search path to Domains=ubuntu.com globally in resolved.conf still breaks ubuntu.com, of course. Out of curiosity, I then put this in resolved.conf:
>
> Domains=uni-konstanz.de inf.uni-konstanz.de disy.inf.uni-konstanz.de
> ubuntu.com
>
> This works for the domains listed in the interface, honoring the search
> path and correctly resolving both short (git) and long (git.uni-
> konstanz.de) domains. But it breaks resolution completely for ubuntu.com
> and subdomains.
>
> So: Does systemd-resolved need to have a network interface "associated"
> with each search domain?? This is very much not how DNS works but it's a
> boundary case that might be easy to get wrong.
>
> (This is all on the 17.10 VM, and with resolved.conf empty apart from
> [Resolve] and the Domains= line, where mentioned.)
>

If there is per-interface configuration available resolved will use
that, and it is preferred mode of operation. Anything else is
ambiguous.

This is to support split-dns situations such that company.internal.vpn
on a a VPN interface can have Domains specified and thus not leak
VPN-intended queries to the general intenet / gateway nameserver.

I'm still struggling to comprehend the obsession of adding
"ubuntu.com" in your examples. Please stop doing that. This is not a
domain you control, and not something one should be trying to
override, as that carries risk of failing to resolve or miss-resolve
domain names used for updates.

If DHCP is not providing you the correct domains all clients should be
using on a given connection -> please fix your DHCP server config.
If that is not possilbe -> you can fix that up locally on per-connection basis.
Lease ubuntu.com alone.

Can you describe in general terms, what network configuration exists,
and how is it broken by default when artful is used as a DHCP client?
It is intentional that DHCP server is not providing the correct search
domains? Why are you overriding them on each client? Why are you
trying to override resolution of ubuntu.com domains?

It is intentional that one has to maintain correct per-link
configuration. This used to happen with resolvconf, as each dhcp v4
and v6 configs were kept separately internally, and were correctly
removed each time a lease/link was lost. Now in addition to keeping
track of which nameserver belogs to which link, we also only send
queries to the right nameservers and matching domains by default. This
improves security and privacy.

https://www.freedesktop.org/software/systemd/man/systemd.network.html#UseDomains=
for more information on a tri-state option for this, in Ubuntu this
option is set to 'true' by default.

-- 
Regards,

Dimitri.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1714803

Title:
  Search list in resolv.conf breaks resolving for that domain

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Ubuntu 17.04
  systemd 232-21ubuntu5

  Adding a domain to the search list in /etc/resolv.conf breaks
  resolving for that domain. Not only does the search list not get used
  as expected, but host names in the domain cannot be resolved by
  systemd-resolved at all.

  I just ran into this after upgrading from ubuntu 16.04 to 17.04 which
  enabled systemd-resolved. I have for a long time used resolveconf to
  add a 'search my-domain'-line to my /etc/resolv.conf.

  Example of expected behaviour. With Googles DNS server (8.8.8.8) and ubuntu.com in the search list in /etc/resolv.conf. Both dig and systemd-resolve can resolve www.ubuntu.com and www:

      $ cat /etc/resolv.conf 
      nameserver 8.8.8.8
      search ubuntu.com
      $ dig +nostat +nocmd www.ubuntu.com
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55037
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 512
      ;; QUESTION SECTION:
      ;www.ubuntu.com.			IN	A

      ;; ANSWER SECTION:
      www.ubuntu.com.		501	IN	A	91.189.89.115

      $ dig +search +nostat +nocmd www
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25772
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 512
      ;; QUESTION SECTION:
      ;www.ubuntu.com.			IN	A

      ;; ANSWER SECTION:
      www.ubuntu.com.		382	IN	A	91.189.89.103

      $ systemd-resolve www.ubuntu.com
      www.ubuntu.com: 91.189.89.115

      -- Information acquired via protocol DNS in 2.7ms.
      -- Data is authenticated: no
      $ systemd-resolve www
      www: 91.189.90.59
           (www.ubuntu.com)

      -- Information acquired via protocol DNS in 3.8ms.
      -- Data is authenticated: no

  Ubuntu 17.04 default config, with the systemd-resolved name server in
  /etc/resolv.conf and no search list. www.ubuntu.com can still be
  resolved correctly:

      $ cat /etc/resolv.conf
      nameserver 127.0.0.53
      $ dig +nostat +nocmd www.ubuntu.com
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64646
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 65494
      ;; QUESTION SECTION:
      ;www.ubuntu.com.			IN	A

      ;; ANSWER SECTION:
      www.ubuntu.com.		482	IN	A	91.189.89.110
      $ systemd-resolve www.ubuntu.com
      www.ubuntu.com: 91.189.90.58

      -- Information acquired via protocol DNS in 18.2ms.
      -- Data is authenticated: no

  Broken behaviour, using the systemd-resolved name server and specify
  ubuntu.com in search list. Resolving fails for www.ubuntu.com and www,
  both using dig (DNS) and using sytemd-resolve:

      $ cat /etc/resolv.conf
      nameserver 127.0.0.53
      search ubuntu.com
      $ dig +nostat +nocmd www.ubuntu.com
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33334
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 65494
      ;; QUESTION SECTION:
      ;www.ubuntu.com.			IN	A

      $ dig +search +nostat +nocmd www
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50588
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 65494
      ;; QUESTION SECTION:
      ;www.ubuntu.com.			IN	A

      $ systemd-resolve www.ubuntu.com
      www.ubuntu.com: resolve call failed: No appropriate name servers or networks for name found
      $ systemd-resolve www
      www: resolve call failed: All attempts to contact name servers or networks failed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1714803/+subscriptions