Comment 17 for bug 1750884

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?