DNS entries for MAAS servers change to secondary IPs

Does the boot interface for the host change at any time?

I've been analyzing this, and I checked that maas picked it as reverse order as

https://bugs.launchpad.net/maas/+bug/1600259

and

https://github.com/maas/maas/blob/master/src/maasserver/dns/zonegenerator.py#L399

I can test this in virtual machine easily.

Added description but comment as well

As this patch https://bugs.launchpad.net/maas/+bug/1600259, it takes IPs reversely and generate zone file.

https://github.com/maas/maas/blob/0c069f0aafbb650928f6c8536debd0de79eb7484/src/maasserver/dns/zonegenerator.py#L399

e.g

assume there is one nic which has 172.16.116.131 as a primary IP.

after adding one more ip to the same nic, zone file refer to secondary IP instead of primary IP.

{<Domain: name=maas>: defaultdict(<class 'maasserver.models.staticipaddress.HostnameIPMapping'>, {'xtrusia.maas': HostnameIPMapping('pca68y', 30, {'172.16.116.131'}, 4, None, None), 'ens33.xtrusia.maas': HostnameIPMapping('pca68y', 30, {'172.16.116.254'}, 4, None, 3), 'lxdbr0.xtrusia.maas': HostnameIPMapping('pca68y', 30, {'10.69.50.1'}, 4, None, 3)}), <Subnet: 172.16.116.0/24:172.16.116.0/24(vid=0)>: defaultdict(<class 'maasserver.models.staticipaddress.HostnameIPMapping'>, {'xtrusia.maas': HostnameIPMapping('pca68y', 30, {'172.16.116.254'}, 4, None, None), 'ens33.xtrusia.maas': HostnameIPMapping('pca68y', 30, {'172.16.116.131'}, 4, None, 3), 'lxdbr0.xtrusia.maas': HostnameIPMapping('pca68y', 30, {'10.69.50.1'}, 4, None, 3)}), 'reverse': defaultdict(<class 'maasserver.models.staticipaddress.HostnameIPMapping'>, {'xtrusia.maas': HostnameIPMapping('pca68y', 30, {'172.16.116.254'}, 4, None, None), 'ens33.xtrusia.maas': HostnameIPMapping('pca68y', 30, {'172.16.116.131'}, 4, None, 3), 'lxdbr0.xtrusia.maas': HostnameIPMapping('pca68y', 30, {'10.69.50.1'}, 4, None, 3)})}

I printed info from code, xtrusia.maas had 172.16.116.131 in the beginning, but after I added 172.16.116.254, it is changed to later.

reproduction step further.

0. deploy machine for maas. ( in my case, virtual machine )
1. deploy maas
- sudo snap install maas
- setup maas-test-db
- setup admin

2. ssh into the machine
- ip a
ens4f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    ...
    inet 10.0.0.55/24 brd 10.0.0.255 scope global ens4f0
       valid_lft forever preferred_lft forever
- cat /var/snap/maas/current/bind/zone.0.0.10.in-addr.arpa
...
@ 30 IN NS maas.
55 30 IN PTR node-20.maas.

3. add additional ip to ens4f0
- sudo ip a a 10.0.0.100 dev ens4f0
- ip a
ens4f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:97:25:20 brd ff:ff:ff:ff:ff:ff
    altname enp0s4f0
    inet 10.0.0.55/24 brd 10.0.0.255 scope global ens4f0
       valid_lft forever preferred_lft forever
    inet 10.0.0.100/32 scope global ens4f0
       valid_lft forever preferred_lft forever

4. few mins later
- cat /var/snap/maas/current/bind/zone.0.0.10.in-addr.arpa
...
100 30 IN PTR node-20.maas.
55 30 IN PTR ens4f0.node-20.maas.

Seyeong, is this reproducible with the latest edge MAAS (3.4.0-beta3)? We've been investigating and fixing a similar issue and the fix recently landed there.

Hello @jhusakowski

I tested it with 3.4.0-beta3 snap in edge. but it has same behavior

ubuntu@node-20:~$ cat /var/snap/maas/current/bind/zone.0.0.10.in-addr.arpa
; Zone file modified: 2023-06-09 00:07:55.343496.
$TTL 30

...

@ 30 IN NS maas.
51 30 IN PTR node-20.maas.

After

ubuntu@node-20:~$ cat /var/snap/maas/current/bind/zone.0.0.10.in-addr.arpa
; Zone file modified: 2023-06-09 00:10:09.763022.
$TTL 30

...

@ 30 IN NS maas.
100 30 IN PTR node-20.maas.
51 30 IN PTR ens4f0.node-20.maas.

I analyzed a bit more, reverse is not the thing.

actually mappings Subnet has already modified values.

keep researching..

{
  <Domain: name=maas>:
    defaultdict(<class 'maasserver.models.staticipaddress.HostnameIPMapping'>,
    {
      'node-20.maas': HostnameIPMapping('hre8hh', 30, {'10.0.0.100'}, 4, None, None),
      'ens4f0.node-20.maas': HostnameIPMapping('hre8hh', 30, {'10.0.0.51'}, 4, None, 1)
    }),
  <Subnet: 10.0.0.0/24:10.0.0.0/24(vid=0)>:
    defaultdict(<class 'maasserver.models.staticipaddress.HostnameIPMapping'>,
    {
      'node-20.maas': HostnameIPMapping('hre8hh', 30, {'10.0.0.100'}, 4, None, None),
      'ens4f0.node-20.maas': HostnameIPMapping('hre8hh', 30, {'10.0.0.51'}, 4, None, 1)
    }
  ),
  'reverse':
    defaultdict(<class 'maasserver.models.staticipaddress.HostnameIPMapping'>,
    {
      'node-20.maas': HostnameIPMapping('hre8hh', 30, {'10.0.0.100'}, 4, None, None),
      'ens4f0.node-20.maas': HostnameIPMapping('hre8hh', 30, {'10.0.0.51'}, 4, None, 1)
    }
  )
}

I checked code a bit more.

https://pastebin.ubuntu.com/p/jYhdxqKQfR/

one more left outer join make order changed

i think this is the point.

Could you please give me any advices?

Thanks.

I proposed merge request

There's a newer fix in 3.4.0, it'd be interesting to know if you can reproduce the issue using that fix. Could you test it on MAAS from this ppa? https://launchpad.net/~cgrabowski/+archive/ubuntu/maas-next

@jhusakowski

I can't install that ppa I see build is failed.

I'll test after fixing it.

Thanks in advance.!

@Jerzy, I am running the 3.4/edge snap

root@maas:~# snap list maas
Name Version Rev Tracking Publisher Notes
maas 3.4.0~rc1-14285-g.358798bbf 29143 3.4/edge canonical✓ -

I am presuming this should have the aforementioned fix, if so, I was able to reproduce this in my lab

root@maas:~# cat /var/snap/maas/current/bind/zone.1.168.192.in-addr.arpa | grep maas.maas
6 30 IN PTR maas.maas.
22 30 IN PTR eth0.maas.maas.

root@maas:~# grep -E "192.168.1.6|192.168.1.22" /var/snap/maas/current/bind/*
grep: /var/snap/maas/current/bind/cache: Is a directory
/var/snap/maas/current/bind/zone.maas:maas 30 IN A 192.168.1.6
/var/snap/maas/current/bind/zone.maas:eth0.maas 30 IN A 192.168.1.22
/var/snap/maas/current/bind/zone.maas-internal:192-168-1-0--24 15 IN A 192.168.1.6
/var/snap/maas/current/bind/zone.maas-internal:192-168-1-0--24 15 IN A 192.168.1.22

MAAS bug-council,

Can this fix be included/targeted to series 3.3 and 3.2 as well?

If so, SEG will proceed with older series afterward.

Thanks,
Mauricio

The change proposed by Seyeong landed in master (3.5), but not yet in 3.4. We targeted the issue to 3.4 as well and need to confirm the fix. The intention is to backport the fix to all affected supported revisions.