No documented way to set a default DNS server if no per-interface servers exist

[Mike Pontillo]

If no per-interface DNS service is defined, MAAS normally falls back to specifying a global default DNS server (probably specifying itself, since it is responsible for DNS for both query forwarding and MAAS hosts).

It looks like netplan only allows DNS servers to be set up on a per-interface basis.

If MAAS does not have *any* per-interface[1] DNS information, should we render a netplan configuration where *every single interface* uses the default DNS server? Or should the concept of a global DNS server be supported in netplan?

Closely related (enough that I'm not sure we need a separate bug) is that MAAS has a global search list (consisting of all the domains it manages), but not a per-interface search list (which would be a nice feature). So without support for a global search list, MAAS is again stuck appending each search domain to *every* interface.

I'm thinking of adding a "nameservers" entry (alongside "ethernets") to prevent information loss, for now, which would contain any default DNS servers, plus the search list.

[1]: (actually in MAAS per-subnet in MAAS, but that's a minor detail)

[Mathieu Trudel-Lapierre (cyphermox)]

There are no ways to currently write global nameservers with the supported renderers (neither networkd nor NetworkManager have a concept of "global" nameservers, and instead encode this per-interface).

There's some potential to setting resolved fallback nameservers, but those remain *fallback* rather than alternate nameservers that apply to all interfaces.

Furthermore, there is not much point in writing global nameservers when you will need at least one interface to reach them anyway. At the current time, it is better to repeat the information for each interface where it makes sense, and omit "global" nameservers for the interfaces where they might not be reachable at all.

[Mathieu Trudel-Lapierre (cyphermox)]

I'm keeping this open in Triaged / unassigned so that we can address it if there is a clear use case where encoding global nameservers would be required (such as for a different yet-to-be-implemented renderer).

[Mike Pontillo (mpontillo)]

Adding a MAAS task; if a fix lands for this in Netplan, we'll want to change MAAS to generate cleaner Netplan.

Related is bug #1671756 which is the fix needed in MAAS in order to generate Netplan equivalent to the current v1 YAML.

[Mike Pontillo (mpontillo)]

Another note on this: today I'm visiting a customer and the issue of "default DNS" came up. The normal use case for MAAS is "everything points to the MAAS server", which implies no special DNS setup on a per-subnet/per-interface basis.

The way this is currently accomplished with curtin is to write the default DNS servers into the loopback interface declaration in /etc/network/interfaces.

Is it possible to do something similar with networkd?

Another way I've solved this personally is to create a bridge that isn't connected to any external interfaces and place the configuration there, such as:

    # Host-only bridge for containers.
    iface host0 inet manual
        bridge_ports none
        bridge_stp off
        bridge_waitport 0
        bridge_fd 0
        dns-nameserver 8.8.8.8
        dns-nameserver 8.8.4.4

[Ryan Harper (raharper)]

On Tue, Mar 21, 2017 at 9:56 AM, Mike Pontillo <email address hidden>
wrote:

> Another note on this: today I'm visiting a customer and the issue of
> "default DNS" came up. The normal use case for MAAS is "everything
> points to the MAAS server", which implies no special DNS setup on a per-
> subnet/per-interface basis.
>
> The way this is currently accomplished with curtin is to write the
> default DNS servers into the loopback interface declaration in
> /etc/network/interfaces.
>
> Is it possible to do something similar with networkd?
>

I'm not sure if it does this natively, a workaround that I'm applying
in cloud-init's rendering of netplan config is to repeat "global" dns config
on each interface.

I'm not sure that cloud-init or curtin (or even netplan) could know if a
global dns route makes "sense" on a particular interface or not; but
maybe at the MAAS level would have enough information.

[Steve Langasek (vorlon)]

If you are configuring a DNS server, you must have a route to that DNS server. The routing information should be part of the yaml: this would manifest as either a static route possibly the default route), or a declaration that the interface should be autoconfigured (dhcp). So MAAS should already have enough information to know which subset of interfaces to attach the DNS server settings to. Is there a reason not to construct the yaml this way?

This seems to map more correctly to the underlying primitives on networkd and network-manager, and I think we should only change the yaml definition if we think we need to support something that can't be represented this way. An example I could think of would be that you want to express "auto-configure this interface with dhcp, which should give you a default route; and may give you dns servers; but just in case it doesn't, here are some fallback servers that you should list with lower priority." That could be a reason to define top-level dns servers that are then fed into resolved directly, rather than to networkd / network-manager. But I doubt this is the use case MAAS cares about?

[Mike Pontillo (mpontillo)]

There are two DNS concepts in MAAS that are relevant here:

 - Default DNS server
 - Per-subnet DNS server

If MAAS has information on DNS servers that can/should be used when an IP address is configured on a particular subnet, then you are correct: MAAS can associate the DNS server with the YAML for that specific subnet (and ultimately its interface definition in the YAML).

If MAAS only knows what the default DNS server is and doesn't have any per-subnet information, such as the common case of using a public DNS server, or upstream corporate DNS server, then you are correct: MAAS would need to compute which interface(s) should have that DNS server configured based on [potentially overlapping] static routing via particular interfaces, and/or and the interface being used as the default gateway.

If the interface is configured with DHCP, right now I'm not worried about trying to override the default DNS server(s). That should be left up to the DHCP server to decide.

[Steve Langasek (vorlon)]

If there is no intention of merging a list of static, default DNS servers with DHCP-provided servers, then I think this should be handled in the input as described by expanding the DNS information out per interface that routes to it. Therefore marking this wontfix for netplan.

[Marco Paulo Martins Sousa (marcomsousa)]

Won't Fix, but was fixed in https://bugs.launchpad.net/cloud-init/+bug/1750884.