[2.5] MAAS uses observed IP address that doesn't exist in a controller to configure internal DNS

[Andres Rodriguez]

MAAS is running in a VM with two interfaces. One of which doesn't have any ip addresses:

root@autopkgtest:/etc/bind/maas# ip addr sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether de:ad:be:ef:6b:b3 brd ff:ff:ff:ff:ff:ff
    inet 10.245.136.6/21 brd 10.245.143.255 scope global ens4
       valid_lft forever preferred_lft forever
    inet6 fe80::dcad:beff:feef:6bb3/64 scope link
       valid_lft forever preferred_lft forever

However, one IP is added for the internal domain that doesn't exist:

root@autopkgtest:/etc/bind/maas# cat zone.maas-internal
; Zone file modified: 2018-10-12 20:44:32.390833.
$TTL 15
@ IN SOA maas-internal. nobody.example.com. (
              0000000127 ; serial
              600 ; Refresh
              1800 ; Retry
              604800 ; Expire
              15 ; NXTTL
              )

@ 15 IN NS maas.
10-245-136-0--21 15 IN A 10.245.136.18
10-245-136-0--21 15 IN A 10.245.136.6

If we look at the db shell, we see:

autopkgtest | 1 | ens3 | physical | 52:54:00:12:34:56 | 10.245.136.18 | DISCOVERED | 10.245.136.0/21 | 0 | fabric-0
autopkgtest | 2 | ens4 | physical | de:ad:be:ef:6b:b3 | 10.245.136.6 | STICKY | 10.245.136.0/21 | 0 | fabric-0

********* A ver interesting thing, is that there's another machine in the subnet, with potentially the same hostname ?

[Mike Pontillo (mpontillo)]

This is an unusual case. Usually when MAAS has a DHCP IP address for a controller, it's accurate. In this situation, we seem to have a case where a machine with a duplicate MAC (elsewhere in the network, but the same as the controller?) has acquired an IP address. MAAS then associates that DHCP IP address with the controller.

It seems that one possible solution to this issue might be to change the IP address selection algorithm so that if it sees two types of IP addresses in the same subnet for the controller, it should always prefer the non-DHCP address.

The other possible solution is to remove the machine that is requesting the rogue IP address for the controller's MAC. ;-)