MAAS

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

Bug #1599223 reported by Stefan Fleischmann
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
Undecided
Unassigned
2.0
Fix Released
Undecided
Unassigned
apache2 (Ubuntu)
New
Undecided
Unassigned

Bug Description

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)

Related branches

lp:~lamont/maas/bug-1599223
Mike Pontillo (community): Approve
Diff: 539 lines (+164/-112)
6 files modified
src/maasserver/dns/tests/test_zonegenerator.py (+11/-22)
src/maasserver/dns/zonegenerator.py (+1/-35)
src/maasserver/models/dnsresource.py (+6/-3)
src/maasserver/models/staticipaddress.py (+61/-16)
src/maasserver/models/tests/test_dnsresource.py (+2/-2)
src/maasserver/models/tests/test_staticipaddress.py (+83/-34)
lp:~lamont/maas/bug-1599223-2.0
LaMont Jones (community): Approve
Diff: 696 lines (+237/-135)
6 files modified
src/maasserver/dns/tests/test_zonegenerator.py (+11/-22)
src/maasserver/dns/zonegenerator.py (+12/-38)
src/maasserver/models/dnsresource.py (+6/-3)
src/maasserver/models/staticipaddress.py (+102/-36)
src/maasserver/models/tests/test_dnsresource.py (+2/-2)
src/maasserver/models/tests/test_staticipaddress.py (+104/-34)
Lee Trager (ltrager)
Changed in maas:
status: New → Triaged
Revision history for this message
LaMont Jones (lamont) wrote :

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.

Revision history for this message
LaMont Jones (lamont) wrote :

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.

Revision history for this message
LaMont Jones (lamont) wrote :

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.)

LaMont Jones (lamont)
Changed in maas:
milestone: none → 2.0.0
summary: - ambigious reverse DNS lookups because MAAS creates multiple PTR records
+ [2.0] confusing reverse DNS lookups because MAAS creates multiple PTR
+ records
Andres Rodriguez (andreserl)
Changed in maas:
milestone: 2.0.0 → 2.1.0
MAAS Lander (maas-lander)
Changed in maas:
status: Triaged → Fix Committed
Revision history for this message
Stefan Fleischmann (sfleischmann) wrote :

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

Revision history for this message
LaMont Jones (lamont) wrote :

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.

Andres Rodriguez (andreserl)
Changed in maas:
milestone: 2.0.1 → next
Andres Rodriguez (andreserl)
Changed in maas:
status: Fix Committed → Fix Released
Andres Rodriguez (andreserl)
Changed in maas:
milestone: next → none
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.