[2.0] confusing reverse DNS lookups because MAAS creates multiple PTR records

[Stefan Fleischmann]

Hi,

we am running MAAS 2.0.0~beta8+bzr5134-0ubuntu1~xenial1. I noticed that it creates two PTR records for each address, for example here is the answer section of dig -x:

1.1.1.10.in-addr.arpa. 30 IN PTR enp1s0.test2.maas.
1.1.1.10.in-addr.arpa. 30 IN PTR test2.maas.

This leads to some problems, for example with Apache mod_authz_host which does reverse lookups and gets a different answers every time (well 50/50 chance to get either one of the two to be more precise).
Also deployed hosts think their fqdn is of the first type, others the second type. I suppose this is not necessarily a bug but imho having multiple PTR records for the same address is not the best idea either.

||/ Name Version Architecture Description
+++-===================================-======================-======================-============================================================================
ii maas 2.0.0~beta8+bzr5134-0u all "Metal as a Service" is a physical cloud and IPAM
ii maas-cli 2.0.0~beta8+bzr5134-0u all MAAS client and command-line interface
un maas-cluster-controller <none> <none> (no description available)
ii maas-common 2.0.0~beta8+bzr5134-0u all MAAS server common files
ii maas-dhcp 2.0.0~beta8+bzr5134-0u all MAAS DHCP server
ii maas-dns 2.0.0~beta8+bzr5134-0u all MAAS DNS server
ii maas-proxy 2.0.0~beta8+bzr5134-0u all MAAS Caching Proxy
ii maas-rack-controller 2.0.0~beta8+bzr5134-0u all Rack Controller for MAAS
ii maas-region-api 2.0.0~beta8+bzr5134-0u all Region controller API service for MAAS
ii maas-region-controller 2.0.0~beta8+bzr5134-0u all Region Controller for MAAS
un maas-region-controller-min <none> <none> (no description available)
un python-django-maas <none> <none> (no description available)
un python-maas-client <none> <none> (no description available)
un python-maas-provisioningserver <none> <none> (no description available)
ii python3-django-maas 2.0.0~beta8+bzr5134-0u all MAAS server Django web framework (Python 3)
ii python3-maas-client 2.0.0~beta8+bzr5134-0u all MAAS python API client (Python 3)
ii python3-maas-provisioningserver 2.0.0~beta8+bzr5134-0u all MAAS server provisioning libraries (Python 3)

[LaMont Jones (lamont)]

This will be fixed by adding A/AAAA RRsets for the interface names (first format above). If the second format (non-interface) is given to mod_authz_host, then either answer will work.

Having said that, this is actually a bug in mod_authz_host, which should grant access if ANY of the PTR RRset names matches the list of allowed hosts.

[LaMont Jones (lamont)]

For purposes of charming, the apache charm (or whatever) will need to add all of the PTR RRset names to the authorized list, to work around the apache bug.

[LaMont Jones (lamont)]

Having said all that, I'm now leaning toward not putting the interface name PTR on the IPs of boot interfaces, since that seems to be the more general mode.

Note however: if multiple names resolve to the same IP, then all of them will be in the PTR RRset. (Since this is a valid and often service-required state.)

[Stefan Fleischmann (sfleischmann)]

Thanks for the clarification, I did not notice that MAAS does not create A records for <interface>.<host>.<domain>. If I create them manually mod_authz_host succeeds.

By the way here is the debug log output from Apache's error.log:
[Sat Jul 09 11:53:57.366338 2016] [authz_host:error] [pid 26131:tid 139886547891968] [client 10.1.1.1:50694] AH01753: access check of 'test2.maas' to /1.txt failed, reason: unable to get the remote host name
[Sat Jul 09 11:53:57.366520 2016] [authz_core:debug] [pid 26131:tid 139886547891968] mod_authz_core.c(809): [client 10.1.1.1:50694] AH01626: authorization result of Require host test2.maas: denied
[Sat Jul 09 11:53:57.366602 2016] [authz_core:debug] [pid 26131:tid 139886547891968] mod_authz_core.c(809): [client 10.1.1.1:50694] AH01626: authorization result of <RequireAny>: denied
[Sat Jul 09 11:53:57.366754 2016] [authz_core:error] [pid 26131:tid 139886547891968] [client 10.1.1.1:50694] AH01630: client denied by server configuration: /var/www/html/1.txt

[LaMont Jones (lamont)]

As landed, the FQDN maps to the "primary" IP, and everything else gets IFACE.FQDN -- with possible multi-address and/or multi-PTR RRs in the RRset, which makes sense.