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, but I want 
queries for anything else to hit

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
Bugs, which is subscribed to Ubuntu.

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

To manage notifications about this bug go to:

ubuntu-bugs mailing list

Reply via email to