Comment 16 for bug 1750884

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.