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? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. 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 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 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1750884/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
