Univention Bugzilla – Bug 37504
UDM should not add a ptr record with just the hostname
Last modified: 2016-09-24 15:15:18 CEST
In univention/admin/handlers/__init__.py simpleComputer.__add_dns_reverse_object() if the zoneName could not be determined, just the hostname is used as value for ptr_record/PTRRecord: --- if len( hostname_list ) < 1: hostname_list.append ( name ) ... ... if not results: self.lo.add( 'relativeDomainName=%s,%s' % ( ipPart, zoneDn ), [ \ ( 'objectClass', [ 'top', 'dNSZone' ] ), \ ( 'zoneName', [ ldap.explode_dn( zoneDn, 1 )[ 0 ] ] ), \ ( 'relativeDomainName', [ ipPart ] ) , ( 'PTRRecord', hostname_list ) ] ) --- PTRRecord should to be an FQDN with a preceding dot. This leads to bug37501 in some cases. I was not able to reproduce that, tho' I got into that situations while debugging (don't no why or how. Yesterday the pointer was okay, today it was broken ;))
What should be done in that case? Is this OK: ? hostname_list.append('%s.%s.' % (name, ucr['domainname']))
(In reply to Florian Best from comment #1) > What should be done in that case? > Is this OK: ? > hostname_list.append('%s.%s.' % (name, ucr['domainname'])) This might also be wrong. It looks like as if the forward zone (ucr['domainname']) does not exist or is not correct detected in that case (if it would, hostname_list would not be empty). Maybe it would be the best to simply not add the PTR at all (better to not have one than to have a broken or wrong one?).
When having a look at the second snipped from comment 0 we see that we create dnsZones without objectClass=univentionObject and univentionObjectType=…. I don't think this is wanted behavior, should we change this, too?
I figured out how to reproduce: Add a computer (e.g. DC slave) named "test", with IP 10.200.27.5 and set the DNS reverse zone to (10.200.27 | 10.200.27.5). Open DNS module, go into the forward zone e.g. "mydomain.intranet" and open the host record "test" and change the IP address (ptrRecord) to another IP e.g. 10.200.27.6. Then go into the reverse zone "10.200.27" and delete the pointer record "5" without its referenced objects. Then open the computer object again, add the same reverse zone entry as before and save the object. This newly created pointer record will have only the hostname as ptrRecord attribute.
r 58940 debian/changelog: 10.0.29-32 Bug #37504: PTR Record isn't saved if zoneDN is missing Successful build Package: univention-directory-manager-modules Version: 10.0.29-32.1296.201503130954 Branch: ucs_4.0-0 Scope: errata4.0-1 r 58941 add yaml - 2015-03-13-univention-directory-manager-modules.yaml
r 58942 Adpated the description for the yaml file
Some additional information: an univentionObject is added to the - dns reverse object / ptr record and the - dns forward objct ipv4 and ipv6 what the fix does: Don't create a pointer record if no forward zone could be determined when modifying a computer object.
OK: When the broken state exists now the pointer record is created if also the forward zone entry is added in UMC. No pointer record is created if the forward zone was not set in UMC. This might not be the best user friendly behavior but it is not possible to get a FQDN for that computer object without the forward zone entry. OK: The attribute univentionObjectType is added to the created host and pointer records. OK: YAML
<http://errata.univention.de/ucs/4.0/122.html>
*** Bug 31196 has been marked as a duplicate of this bug. ***