| 2020-09-23 16:29:02 |
Dan Streetman |
description |
maas forces all rack addresses for all subnets in a single vlan to any system deployed into any of those subnets. If the deployed systems are isolated, with no gateway configured, they may end up with broken DNS due to having nameservers configured which are not reachable.
[test case]
configure maas with a single Fabric 'maas', with a single vlan 'untagged'. In that untagged vlan, create 4 separate subnets, 10.1.0.0/24, 10.2.0.0/24, 10.3.0.0/24, and 10.4.0.0/24. Configure all the subnets with 'allow_dns' set to False, and each of them should be configured with 10.X.0.1 as their only dns nameserver, and no gateway. Of course, also configure the corresponding 10.X.0.1 addresses on the maas machine.
Configure a machine in maas to set its interface to use Fabric 'maas' and vlan 'untagged', and subnet 10.1.0.0/24.
Deploy that system, and even though the subnet is configured with "dns_servers": [ "10.1.0.1" ] and "allow_dns": False, the deployed system is configured with 10.1.0.1 as well as 10.2.0.1, 10.3.0.1, and 10.4.0.1.
When deploying a system using systemd-resolved, this is not necessarily a problem, since systemd-resolved has no limit on the number of upstream nameservers it can handle, so the 'correct' (on-subnet) nameserver will be one of the configured ones, and systemd-resolved will use it for DNS.
However, when deploying a system that does not use systemd-resolved, when cloud-init manually edits the /etc/resolv.conf file, there is a hardcoded limit of 3 nameservers that can be listed in the file, so if the list of nameservers is larger, the 'correct' nameserver may not be included. In this example, if the deployed system's resolv.conf file is created with only the 10.2.0.1, 10.3.0.1, and 10.4.0.1 nameservers, the system will have no working DNS since it can only reach 10.1.0.0/24 systems. |
maas forces all rack addresses for all subnets in a single vlan to any system deployed into any of those subnets. If the deployed systems are isolated, with no gateway configured, they may end up with broken DNS due to having nameservers configured which are not reachable.
[test case]
configure maas with a single Fabric 'maas', with a single vlan 'untagged'. In that untagged vlan, create 4 separate subnets, 10.1.0.0/24, 10.2.0.0/24, 10.3.0.0/24, and 10.4.0.0/24. Configure all the subnets with 'allow_dns' set to False, and each of them should be configured with 10.X.0.1 as their only dns nameserver, and no gateway. Of course, also configure the corresponding 10.X.0.1 addresses on the maas machine.
Configure a machine in maas to set its interface to use Fabric 'maas' and vlan 'untagged', and subnet 10.1.0.0/24.
Deploy that system, and even though the subnet is configured with "dns_servers": [ "10.1.0.1" ] and "allow_dns": False, the deployed system is configured with 10.1.0.1 as well as 10.2.0.1, 10.3.0.1, and 10.4.0.1.
When deploying a system using systemd-resolved, this is not necessarily a problem, since systemd-resolved has no limit on the number of upstream nameservers it can handle, so the 'correct' (on-subnet) nameserver will be one of the configured ones, and systemd-resolved will use it for DNS.
However, when deploying a system that does not use systemd-resolved (e.g. Centos), when cloud-init manually edits the /etc/resolv.conf file, there is a hardcoded limit of 3 nameservers that can be listed in the file, so if the list of nameservers is larger, the 'correct' nameserver may not be included. In this example, if the deployed system's resolv.conf file is created with only the 10.2.0.1, 10.3.0.1, and 10.4.0.1 nameservers, the system will have no working DNS since it can only reach 10.1.0.0/24 systems. |
|
