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

[Andres Rodriguez]

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@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@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@node01:~$ ping google.com
ping: google.com: Temporary failure in name resolution

[...]

ubuntu@node01:~$ sudo vim /etc/resolv.conf
ubuntu@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@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@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@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

Related bugs:
 * bug 1774540: bionic: DNS search domains lost from cloud-init to netplan

[Andres Rodriguez (andreserl)]

This is pretty critical to MAAS as this yield Bionic deployments without DNS resolution.

[Scott Moser (smoser)]

Hi,

cloud-init has never updated resolv.conf directly.
/etc/resolv.conf in 16.04 is managed via resolvconf through /etc/network/interfaces.
/etc/resolv.conf in 18.04 is managed via systemd-resolve (netplan -> systemd-networkd -> systemd-resolve).

Can you provide the content of:
   systemd-resolve --status --no-pager

And does this happen in the ephemeral environment, the installed environment, or both?

[Andres Rodriguez (andreserl)]

ubuntu@node03:~$ systemd-resolve --status --no-pager
Global
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 3 (br0)
      Current Scopes: LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 2 (enp0s25)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 10.90.90.1
          DNS Domain: maaslab
                      maas

[Mathieu Trudel-Lapierre (cyphermox)]

Why aren't the nameservers set under the br0 interface, if the interface is supposed to be in a bridge?

The /e/n/i config and netplan configs here are not equivalent. I expect that systemd-resolved should be happy with the config as it is anyway, but this may be a special case where systemd thinks the interface is not really up?

If you run 'systemd-resolve google.com', what happens?

[Andres Rodriguez (andreserl)]

@Mathieu,

Good catch.

@Scott:

Network config MAAS sent is correect, it is the same config sent to xenial: https://pastebin.canonical.com/p/rjBgzKjdxR/

[Scott Moser (smoser)]

MAAS is sending a "global" nameserver, and a ethernet device on a bridge.
cloud-init is rendering that nameserver onto the ethernet device rather
than on the bridge or as a "global" entry.

$ cat my.yaml
network:
  config: [
   {"id": "enp0s25", "type": "physical", "name": "enp0s25",
    "mac_address": "b8:ae:ed:7d:16:d0", "mtu": 1500,
    "subnets": [{"type": "manual"}]},
   {"id": "br0", "type": "bridge", "name": "br0",
    "mac_address": "b8:ae:ed:7d:16:d0", "bridge_interfaces": ["enp0s25"],
    "mtu": 1500, "params": {'bridge_fd': 15, 'bridge_stp': 0},
    "subnets": [
       {"type": "static", "address": "10.90.90.4/24", "dns_nameservers": [],
        "gateway": "10.90.90.1"}
     ]},
   {"type": "nameserver", "address": ["10.90.90.1"],
    "search": ["maaslab", "maas"]},
  ]
  version: 1

$ PYTHONPATH=$PWD python3 ./tools/net-convert.py \
   --network-data=my.yaml --kind=yaml --output-kind=netplan --directory=out.d

$ cat out.d/etc/netplan/50-cloud-init.yaml

network:
    version: 2
    ethernets:
        enp0s25:
            match:
                macaddress: b8:ae:ed:7d:16:d0
            mtu: 1500
            nameservers:
                addresses:
                - 10.90.90.1
                search:
                - maaslab
                - maas
            set-name: enp0s25
    bridges:
        br0:
            addresses:
            - 10.90.90.4/24
            gateway4: 10.90.90.1
            interfaces:
            - enp0s25
            parameters:
                forward-delay: 15
                stp: false

[Andres Rodriguez (andreserl)]

@Matthieu,

ubuntu@node01:~$ systemd-resolve google.com
google.com: resolve call failed: No appropriate name servers or networks for name found

[Scott Moser (smoser)]

It seems to me that each of maas, cloud-init and netplan could do better here.

a.) maas declares 'global' nameserver/dns info.
this is kind of silly in that such a thing doesn't really exist.
maas has the information necessary to declare the nameserver on the
device with the address that has a route to it.

b.) cloud-init is currently sticking that global definition on an
interface that doesnt have an address. so cloud-init could do better.

c.) netplan or systemd-networkd could realize enp0s25 interface is "up"
and that it should have its nameservers used.

[Dimitri John Ledkov (xnox)]

In terms of expectations on bionic:

1) /etc/resolv.conf should be a symlink to ../run/systemd/resolve/stub-resolv.conf

2) The contents should point at `nameserver 127.0.0.53` and list search domains, if any are available. I.e. the contents shown in the bug description is correct.

3) The nameservers are now preferred to be on the per-interface basis, thus e.g. nameserver should be declared on the interface that has the default route. Indeed sending "global" configs is loss of information about networking.

[Andres Rodriguez (andreserl)]

@Scott,

Sure, we can all improve but I just want to note one thing. The "Silly" config that MAAS sends to curtin is valid config. That yields valid configuration in Xenial. Since Curtin is now passing the /same/ configuration to cloud-init, cloud-init is not generating valid configuration in Bionic. Despite the fact that theres a "global" DNS, there's also DNS defined for the bridge, but cloud-init is not writing the bridge config correctly.

[Dean Henrichsmeyer (dean)]

Let's make sure this is fixed for bionic. The scope of nameservers has changed and maas should do the right thing.

[Ryan Harper (raharper)]

I gave the "loopback" trick a go like so:

root@b1:~# cat /etc/systemd/network/10-netplan-lo.network
[Match]
Name=lo

[Network]
Address=127.0.0.1
DNS=10.90.90.1
Domains=maaslab maas
root@b1:~# networkctl status --all
● 1: lo
       Link File: n/a
    Network File: /etc/systemd/network/10-netplan-lo.network
            Type: loopback
           State: carrier (configured)
         Address: 127.0.0.1
                  ::1
             DNS: 10.90.90.1
  Search Domains: maaslab
                  maas

● 38: eth0
       Link File: n/a
    Network File: /run/systemd/network/10-netplan-eth0.network
            Type: ether
           State: routable (configured)
      HW Address: 00:16:3e:4c:5b:4b (Xensource, Inc.)
         Address: 10.8.107.71
                  fe80::216:3eff:fe4c:5b4b
         Gateway: 10.8.107.1
             DNS: 10.8.107.1
  Search Domains: lxd
root@b1:~# systemd-resolve --status --no-pager
Global
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 38 (eth0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 10.8.107.1
          DNS Domain: lxd

networkctl processed the .network file but systemd-resolved didn't seem to notice it.

[Scott Moser (smoser)]

Getting this fixed in cloud-init is tricky.
In ifupdown (/etc/network/interfaces) world, we just took the "global dns" entries and put them on the loopback device (lo). Since that device would always be brought up, and never really brought down, it served its purpose.

That is what Ryan tried above, but it doesnt seem to work. Even if it *did* work, the solution would be systemd-networkd specific, and cloud-init doesn't speak to systemd-networkd or systemd-resolved. It speaks to netplan. So we would still need a way for cloud-init to tell netplan to do this.

That leaves us with 2 not-so-great solutions in cloud-init only:
a.) blindly put global dns entries on *all* interfaces
b.) cloud-init search through the config and find the "right" interface to put the global dns entry on.

[Andres Rodriguez (andreserl)]

On Thu, Feb 22, 2018 at 10:30 PM Scott Moser <email address hidden>
wrote:

> Getting this fixed in cloud-init is tricky.
> In ifupdown (/etc/network/interfaces) world, we just took the "global dns"
> entries and put them on the loopback device (lo). Since that device would
> always be brought up, and never really brought down, it served its purpose.
>
> That is what Ryan tried above, but it doesnt seem to work. Even if it
> *did* work, the solution would be systemd-networkd specific, and cloud-
> init doesn't speak to systemd-networkd or systemd-resolved. It speaks
> to netplan. So we would still need a way for cloud-init to tell netplan
> to do this.
>
> That leaves us with 2 not-so-great solutions in cloud-init only:
> a.) blindly put global dns entries on *all* interfaces
> b.) cloud-init search through the config and find the "right" interface to
> put the global dns entry on.
>

This is the same issue we are facing in MAAS. Unless a user specifies a
specific set of dns servers on a subnet, which is not always the case, then
MAAS doesn’t know which interface the dns servers belong to.

I believe this is one of the reasons why the “global” config was used,
because effectively, the DNS server doesn’t really “belong” to a specific
interface.

So we either sent it to all, interfaces or pick a “best” interface, which
is not the best approach either.

As per mpontillo’s config, this has the likelihood to break dns resolution.

That said, maybe option 3 would be to put th dns on the interface which the
default routes will be going through...

> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1750884
>
> Title:
> [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
> leads to no DNS resolution
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cloud-init/+bug/1750884/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: product=cloud-init; status=New; importance=Undecided;
> assignee=None;
> Launchpad-Bug: product=maas; milestone=2.4.0alpha2; status=Triaged;
> importance=High; <email address hidden>;
> Launchpad-Bug: distribution=ubuntu; sourcepackage=nplan; component=main;
> status=New; importance=Critical; assignee=None;
> Launchpad-Bug: distribution=ubuntu; sourcepackage=systemd; component=main;
> status=New; importance=Critical; assignee=None;
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: andreserl cyphermox dean raharper smoser xnox
> Launchpad-Bug-Reporter: Andres Rodriguez (andreserl)
> Launchpad-Bug-Modifier: Scott Moser (smoser)
> Launchpad-Message-Rationale: Subscriber
> Launchpad-Message-For: andreserl
>
--
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
MSc. Telecom & Networking
Systems Engineer

[Dimitri John Ledkov (xnox)]

If we don't know, then maybe things should be passed to netplan, in a way for it to generate global resolved config? as in, create
/run/systemd/resolved.conf.d/global.conf

[Resolve]
DNS=999.999.999.999
(Maybe FallbackDNS=, if we want it to leave DNS= setting for users to tweak)

Or whatnot, which should then appear in systemd-resolve --status, Global section which is applied as a fallback if an interface does not have a per-interface DNS settings.

Could somebody try dropping dns configs out of netplan file that is generated, rerun apply, check that systemd-resolve --status has nothing, then add above drop-in with the right dns server, restart resolved, and check if that picks up a global DNS server, and if network resolution works correctly? *globally*

I also wonder, if .network / .link files should have an ability to specify Global DNS settings for resolved...

[Steve Langasek (vorlon)]

On Fri, Feb 23, 2018 at 04:09:07AM -0000, Andres Rodriguez wrote:
> On Thu, Feb 22, 2018 at 10:30 PM Scott Moser <email address hidden>
> wrote:

> > Getting this fixed in cloud-init is tricky.
> > In ifupdown (/etc/network/interfaces) world, we just took the "global dns"
> > entries and put them on the loopback device (lo). Since that device would
> > always be brought up, and never really brought down, it served its purpose.

> > That is what Ryan tried above, but it doesnt seem to work. Even if it
> > *did* work, the solution would be systemd-networkd specific, and cloud-
> > init doesn't speak to systemd-networkd or systemd-resolved. It speaks
> > to netplan. So we would still need a way for cloud-init to tell netplan
> > to do this.

> > That leaves us with 2 not-so-great solutions in cloud-init only:
> > a.) blindly put global dns entries on *all* interfaces
> > b.) cloud-init search through the config and find the "right" interface to
> > put the global dns entry on.

> This is the same issue we are facing in MAAS. Unless a user specifies a
> specific set of dns servers on a subnet, which is not always the case, then
> MAAS doesn’t know which interface the dns servers belong to.

> I believe this is one of the reasons why the “global” config was used,
> because effectively, the DNS server doesn’t really “belong” to a specific
> interface.

> So we either sent it to all, interfaces or pick a “best” interface, which
> is not the best approach either.

> As per mpontillo’s config, this has the likelihood to break dns
> resolution.

> That said, maybe option 3 would be to put th dns on the interface which the
> default routes will be going through...

Yes, and option 3 was what I previously recommended when mpontillo raised
this issue in <https://bugs.launchpad.net/netplan/+bug/1664806>.

Given that cloud-init itself has some notion of a "global" DNS server in v1
yaml, I think its v2 yaml renderer should apply the same logic.

[Mike Pontillo (mpontillo)]

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?

[Mathieu Trudel-Lapierre (cyphermox)]

Whether or not /e/n/i supports something correctly or just happens to work by sheer luck has no bearing on what is technically correct and sensical -- let's abstract this, what we need to concern ourselves with here is netplan, cloud-init and maas.

In the network world, it is absolutely true that DNS nameservers only make sense on a per-interface basis: nothing guarantees that a "globally-set" nameserver of 8.8.8.8 is reachable through all interfaces. It just happens to be that way on 99% of systems because they only connect to one network, through one interface.

So, in light of the nameserver setting in MaaS under Settings being unspecified, there's /no other way/ but to either set the nameserver globally or try to guess the right interface (either by which is connected to MaaS, or which gets the default gateway, or which matches subnets). None of the detection options I could come up with strike me as particularly solid and foolproof.

Next steps for netplan strike me as being to add support for global nameservers even if it's silly; we shouldn't expect users to have to have the level of knowledge of networking to know to set it up on a particular interface when it will work correctly as "global" for 99% of cases.

In MaaS, my opinion is that every effort should be taken to allow network administrators to set things up correctly -- nothing guarantees that the systems deployed will remain accessible to MaaS, or that it will be their main interface to the network. Only allowing global DNS is brittle at best, and breaks at least what *I* have been taught were best practices, to have a separate "public" network from the authenticated "private" side where monitoring and/or deployment happens. Maybe I'm just the one who's particular in doing this.

I'm not sure what next steps are for cloud-init -- given a valid configuration, I assumed it should just pass it through to netplan if it's v2.

I'll take care of the "global DNS" implementation in netplan.

[Scott Moser (smoser)]

Currently maas sends v1 config to cloud-init. cloud-init converts
that to netplan. MAAS could certainly change change to either
a.) improve the v1 config that it sends to put dns as per-interface
b.) send v2 config with dns per-interface.

I don't think there is reason to justify either of those at this time.

I do think that at some point MAAS network configuration will be
hindered and they'll end up wanting to describe dns more eloquently.
That time is not yet upon us.

Mathieu, you tell us how to indicate global dns in netplan configuration
and cloud-init will make sure it gets through to netplan correctly.

[Jason Hobbs (jason-hobbs)]

Is there a workaround for this? I can just rm /etc/resolv.conf and create it with the contents I want, right?

[Dan Watkins (oddbloke)]

On Wed, Mar 07, 2018 at 11:42:29PM -0000, Jason Hobbs wrote:
> Is there a workaround for this? I can just rm /etc/resolv.conf and
> create it with the contents I want, right?

Yep, though you'll need to recreate it every so often as it will be
replaced.

[Jason Hobbs (jason-hobbs)]

Ok, that's not much of a workaround then :).

On Thu, Mar 8, 2018 at 3:52 AM, Dan Watkins
<email address hidden> wrote:
> On Wed, Mar 07, 2018 at 11:42:29PM -0000, Jason Hobbs wrote:
>> Is there a workaround for this? I can just rm /etc/resolv.conf and
>> create it with the contents I want, right?
>
> Yep, though you'll need to recreate it every so often as it will be
> replaced.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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@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@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@node01:~$ ping google.com
> ping: google.com: Temporary failure in name resolution
>
> [...]
>
> ubuntu@node01:~$ sudo vim /etc/resolv.conf
> ubuntu@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@node01:~$ ping google.com
> PING google.com (172.217.0.174) 56(84) bytes of data.
> 64 bytes from mi...

[Mike Pontillo (mpontillo)]

We discussed this today and decided that the proper place to fix this is not in MAAS; the v1 YAML containing global DNS servers should be converted to equivalent valid Netplan (using a heuristic).

Alternatively, global DNS could be added to the Netplan schema (possibly as a shortcut to apply configuration to a group of interfaces).

[Scott Moser (smoser)]

I'm pretty sure that if you you rm /etc/resolv.conf
and then just write what ever you want in there, it wont get overritten.

mv /etc/resolv.conf /etc/resolv.conf.dist
echo "nameserver 8.8.8.8" > /etc/resolv.conf

On Thu, Mar 8, 2018 at 4:36 PM, Mike Pontillo <email address hidden>
wrote:

> We discussed this today and decided that the proper place to fix this is
> not in MAAS; the v1 YAML containing global DNS servers should be
> converted to equivalent valid Netplan (using a heuristic).
>
> Alternatively, global DNS could be added to the Netplan schema (possibly
> as a shortcut to apply configuration to a group of interfaces).
>
> --
> You received this bug notification because you are a member of Canonical
> Cloudware, which is subscribed to cloud-init.
> Matching subscriptions: cloud-init bugs
> https://bugs.launchpad.net/bugs/1750884
>
> Title:
> [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
> leads to no DNS resolution
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cloud-init/+bug/1750884/+subscriptions
>

[Dan Watkins (oddbloke)]

On Thu, Mar 08, 2018 at 04:30:30PM -0000, Scott Moser wrote:
> I'm pretty sure that if you you rm /etc/resolv.conf
> and then just write what ever you want in there, it wont get overritten.
>
> mv /etc/resolv.conf /etc/resolv.conf.dist
> echo "nameserver 8.8.8.8" > /etc/resolv.conf

Apologies, I thought I was replying to another "DNS resolution in bionic
doesn't work" bug. >.<

(That said, systemd-resolved does own /etc/resolv.conf, so it _could_
rewrite it. An example would be when the search domain changes, but
that's unlikely in a MAAS environment.)

[Chad Smith (chad.smith)]

An upstream commit landed for this bug.

To view that commit see the following URL:
https://git.launchpad.net/cloud-init/commit/?id=d29eeccd

[Chad Smith (chad.smith)]

This bug is believed to be fixed in cloud-init in 18.2. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

[nucc1 (nucc1)]

I'm using ubuntu 18.04, I have removed cloud-init, but i'm using netplan and systemd-networkd as usual.

I've also disabled the stub dns server (plan is to deploy dnsmasq).

Netplan config is as follows (for test, enp3s0 is unplugged).

network:
    ethernets:
        enp3s0:
            dhcp4: true

        enp4s0:
            addresses: [192.168.1.254/24]
            dhcp4: false
            gateway4: 192.168.1.1
            nameservers:
                addresses: [1.1.1.1,8.8.8.8,8.8.4.4]
    version: 2
    renderer: networkd

I expected that the settings I specified in netplan config would find their way into /etc/resolv.conf somehow, so that things would work correctly.

However, it seems like the system is hard-coded to expect the built-in stub resolver

nucc1@sol:/etc/systemd$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Apr 26 19:07 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Netplan is updating /run/systemd/resolve/resolv.conf

nucc1@sol:/etc/systemd$ cat /run/systemd/resolve/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 1.1.1.1
nameserver 8.8.8.8
nameserver 8.8.4.4

---

shouldn't systemd-resolvd or something, update the /etc/resolv.conf symlink when it's clear that the stub resolver is not in use?

apologies if this is the wrong place and I need to open a new bug instead.

[Ryan Harper (raharper)]

@nucc1

Thanks for the report, could you open a new bug with your steps to recreate? It does sound like the non-systemd-resolved case needs some work in netplan and what the process for transitioning to a non-systemd-resolved scenario.

[mutrax (ed-driesen)]

Hi,
I had my stock xubuntu 18.04 (upgrate from beta and fresh install) with 127.0.0.53 appearing in /etc/resolv.conf . Result: no local dns resolution

Editing /etc/NetworkManager/NetworkManager.conf and adding dns=default to [main] fixed this for me! Now dns is the one my router pushes (asus merin wrt ra-ac66u) via dhcp!

Got my fix @ https://forum.ubuntu-fr.org/viewtopic.php?pid=21743150#p21743150

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3123