[Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

Sat Feb 24 02:11:23 UTC 2018

I don't want to change the v1 YAML in MAAS to output per-interface DNS,
because this risks causing a change of behavior in pre-netplan
deployments. It seems this is necessary in Netplan, but it isn't clear
to me that this is correct. I think it's valuable to take a step back
and look at the requirements here. With DNS resolution being a system-
wide function, is it really correct for it to be associated with a
particular interface? If I think about the user stories, it's:

 - I want to use a specific DNS server to resolve DNS names for a particular forward or reverse domain.
 - I want the set of configured DNS servers to be symmetrical with enabled interfaces. (In other words, if I have a DMZ interface and an internal interface, I might want queries for *.example.com to hit 10.0.0.2, but I want queries for anything else to hit 8.8.8.8.)

Somewhat of a tangent here, but don't like search lists. That just makes
DNS names ambiguous. If my search list is 'example.com', now when I type
"foo.com", the resolver has to decide whether I meant
"foo.com.example.com" or just plain "foo.com". I don't want a /search/
list. I want a /match/ list. (But that sounds like a separate bug.)

Back to the current problem: if we blindly configure global default DNS
servers on interfaces that can't reach them, we risk that resolvconf
will calculate an incorrect global configuration. That is, the MAAS
administrator might have expected that the per-interface configuration
take precedence over the default configuration. Would having default
configuration inside an interface cause it to take priority?

Then again, I'm not entirely clear on what the expected behavior is
here, even for the v1 YAML. If I specify global DNS servers *and* per-
interface DNS servers (for a subset of interfaces), is there an
unambiguous way to render that in /e/n/i?

-- 
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/1750884

Title:
  [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
  leads to no DNS resolution

Status in cloud-init:
  New
Status in MAAS:
  Triaged
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  When deploying Bionic, /etc/resolv.conf is not configured correctly,
  which leads to no DNS resolution. In the output below, you will see
  that netplan config is correctly to the 10.90.90.1 nameserver, but in
  resolv.conf that's a local address.

  Resolv.conf should really be configured to use the provided DNS
  server(s). That said, despite that fact, DNS resolution doesn't work
  with the local address.

  Bionic
  ------

  ubuntu at node01:~$ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
      version: 2
      ethernets:
          enp0s25:
              match:
                  macaddress: b8:ae:ed:7d:17:d2
              mtu: 1500
              nameservers:
                  addresses:
                  - 10.90.90.1
                  search:
                  - maaslab
                  - maas
              set-name: enp0s25
      bridges:
          br0:
              addresses:
              - 10.90.90.3/24
              gateway4: 10.90.90.1
              interfaces:
              - enp0s25
              parameters:
                  forward-delay: 15
                  stp: false
  ubuntu at node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 127.0.0.53

  search maaslab maas
  ubuntu at node01:~$ ping google.com
  ping: google.com: Temporary failure in name resolution

  [...]

  ubuntu at node01:~$ sudo vim /etc/resolv.conf
  ubuntu at node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 10.90.90.1

  search maaslab maas
  ubuntu at node01:~$ ping google.com
  PING google.com (172.217.0.174) 56(84) bytes of data.
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=1 ttl=52 time=4.46 ms
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=2 ttl=52 time=4.38 ms

  =============================
  Xenial
  ==============================

  ubuntu at node05:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback
      dns-nameservers 10.90.90.1
      dns-search maaslab maas

  auto enp0s25
  iface enp0s25 inet static
      address 10.90.90.162/24
      gateway 10.90.90.1
      mtu 1500
  ubuntu at node05:~$ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  nameserver 10.90.90.1
  search maaslab maas

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1750884/+subscriptions