allow_dns=false doesn't take effect - MAAS DNS is added to an interface with allowed_dns=false

[Nobuto Murata]

maas - 1:3.4.0-14318-g.3234f5e2a-0ubuntu1~22.04.1

I think this is a regression since the test case in the following bug described the expected status.
https://bugs.launchpad.net/maas/+bug/1847537

There is a flaky DNS resolution issue observed and it boiled down to unexpected curtin/netplan config generated by MAAS.

Let's say a machine has two (or more) interfaces and one is connected to the main MAAS PXE network and the other is connected to an isolated network (no reachability to MAAS). DNS traffic should be sent from the first interface to MAAS DNS.

However, generated curtin/netplan adds MAAS DNS to the NIC with the isolated network and the DNS traffic goes no where since the isolated network do not have connectivity to MAAS nor any gateway.

[flaky DNS behavior due to the issue]

$ resolvectl dns
Global:
Link 2 (ens4): 192.168.151.1
Link 3 (ens8):
Link 4 (ens9): 192.168.151.1

$ resolvectl reset-server-features

$ for _ in {1..6}; do time resolvectl query --cache=false --interface=ens9 example.com; done
example.com: resolve call failed: Lookup failed due to system error: No route to host

real 0m3.072s
user 0m0.000s
sys 0m0.007s
example.com: resolve call failed: Lookup failed due to system error: No route to host

real 0m3.072s
user 0m0.000s
sys 0m0.006s
example.com: resolve call failed: Lookup failed due to system error: No route to host

real 0m3.072s
user 0m0.000s
sys 0m0.006s
example.com: resolve call failed: Lookup failed due to system error: No route to host

real 0m3.072s
user 0m0.000s
sys 0m0.007s
example.com: 2606:2800:220:1:248:1893:25c8:1946 -- link: ens9
             93.184.216.34 -- link: ens9

-- Information acquired via protocol DNS in 3.9ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

real 0m0.010s
user 0m0.006s
sys 0m0.000s
example.com: 2606:2800:220:1:248:1893:25c8:1946 -- link: ens9
             93.184.216.34 -- link: ens9

-- Information acquired via protocol DNS in 44.0ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

real 0m0.050s
user 0m0.000s
sys 0m0.006s

[deployed node]

$ ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
ens4 UP 192.168.151.116/24 fe80::5054:ff:fe78:ba0d/64
ens8 UP fe80::5054:ff:febf:8f7/64
ens9 UP 192.168.152.101/24 fe80::5054:ff:fea9:2e4/64

$ resolvectl
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens4)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.151.1
       DNS Servers: 192.168.151.1
        DNS Domain: maas

Link 3 (ens8)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 4 (ens9)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.151.1
       DNS Servers: 192.168.151.1
        DNS Domain: maas

^^^ MAAS DNS (192.168.151.1) should be only added to the main NIC en4.

[isolated subnet definition]

maas admin spaces create name=space-isolated
maas admin vlans create "$fabric_id" vid=152 space=space-isolated
maas admin subnets create cidr='192.168.152.0/24' \
    fabric="$fabric_id" vid=152 \
    allow_dns=false
maas admin ipranges create type=reserved \
    start_ip=192.168.152.1 end_ip=192.168.152.100
maas admin ipranges create type=dynamic \
    start_ip=192.168.152.201 end_ip=192.168.152.254

[associating the isolated subnet to a second or third NIC]
vlan_id=$(maas admin vlan read "$fabric_id" 152 | jq -r '.id')
subnet_id=$(maas admin subnets read | jq -r '.[] | select(.cidr=="192.168.152.0/24").id')
for system_id in $(maas admin machines read | jq -r '.[].system_id'); do
    maas admin interface update "$system_id" ens9 vlan="$vlan_id"
    maas admin interface link-subnet "$system_id" ens9 mode='AUTO' subnet="$subnet_id"
done

[Nobuto Murata (nobuto)]

Subscribing ~field-high as it's affecting a partner engagement.

[Nobuto Murata (nobuto)]

`"allow_dns": false` and `"dns_servers": []` are properly reflected in maas machine read.

        {
            "type": "physical",
            "link_speed": 0,
            "mac_address": "52:54:00:a9:02:e4",
            "vendor": "Red Hat, Inc.",
            "links": [
                {
                    "id": 133,
                    "mode": "auto",
                    "ip_address": "192.168.152.101",
                    "subnet": {
                        "name": "192.168.152.0/24",
                        "description": "",
                        "vlan": {
                            "vid": 152,
                            "mtu": 1500,
                            "dhcp_on": false,
                            "external_dhcp": null,
                            "relay_vlan": null,
                            "secondary_rack": null,
                            "id": 13,
                            "primary_rack": null,
                            "name": "152",
                            "space": "space-isolated",
                            "fabric": "fabric-1",
                            "fabric_id": 1,
                            "resource_uri": "/MAAS/api/2.0/vlans/13/"
                        },
                        "cidr": "192.168.152.0/24",
                        "rdns_mode": 2,
                        "gateway_ip": null,
                        "dns_servers": [],
                        "allow_dns": false,
                        "allow_proxy": true,
                        "active_discovery": false,
                        "managed": true,
                        "disabled_boot_architectures": [],
                        "id": 6,
                        "space": "space-isolated",
                        "resource_uri": "/MAAS/api/2.0/subnets/6/"
                    }

[Nobuto Murata (nobuto)]

However, nameservers will be populated to 52:54:00:a9:02:e4 unnecessarily in the curtin config generated by MAAS.

network:
  ethernets:
    ens4:
      addresses:
      - 192.168.151.116/24
      gateway4: 192.168.151.1
      match:
        macaddress: 52:54:00:78:ba:0d
      mtu: 1500
      nameservers:
        addresses:
        - 192.168.151.1
        search: &id001
        - maas
      set-name: ens4
    ens8:
      match:
        macaddress: 52:54:00:bf:08:f7
      mtu: 1500
      set-name: ens8
    ens9:
      addresses:
      - 192.168.152.101/24
      match:
        macaddress: 52:54:00:a9:02:e4
      mtu: 1500
      nameservers:
        addresses:
        - 192.168.151.1
        search: *id001
      set-name: ens9
  version: 2

[Alberto Donato (ack)]

When creating the network configuration for an interface, MAAS should not set nameservers if the subnet is marked as allow_dns=false.

[Nobuto Murata (nobuto)]

Could you please backport this to 3.4 as the latest stable release?