Univention Bugzilla – Bug 44684
Removing a ForwardZone does not remove FQDN from ReverseZone and leaves orphaned associatedDomain behind
Last modified: 2020-07-03 20:54:39 CEST
First of all related Bug#14885 may be announced here! ----- In a customer scenario a client belongs to a fwdzone with an associated network. When the fwdzone has been removed the related FQDN remains in the rvszone, which definitely is wrong. Also the associatedDomain still points to the deleted fwdzone, which probably is correct at this point. Here are the steps to reproduce: * create a fwd-, rvszone and a related network # univention-directory-manager \ dns/forward_zone create \ --position cn=dns,$(ucr get ldap/base) \ --set zone=wastezone.$(ucr get domainname) \ --set nameserver="$(ucr get ldap/master)" # univention-directory-manager \ dns/reverse_zone create \ --set subnet=192.168.2 \ --set nameserver="$(ucr get ldap/master)" # univention-directory-manager \ networks/network create \ --position="cn=networks,$(ucr get ldap/base)" \ --set name=wastenet \ --set netmask=24 \ --set network=192.168.2.0 \ --set ipRange="192.168.2.2 192.168.2.9" \ --set dnsEntryZoneReverse="zoneName=2.168.192.in-addr.arpa,cn=dns,$(ucr get ldap/base)" \ --set dnsEntryZoneForward="zoneName=wastezone.$(ucr get domainname),$(ucr get ldap/base)" * now assign a client to that zone and network. DNS-Records for that client are created automatically # udm computers/ipmanagedclient modify \ --dn "cn=problem,cn=computers,$(ucr get ldap/base)" \ --set network="cn=wastenet,cn=networks,$(ucr get ldap/base)" \ --set dnsEntryZoneForward="zoneName=wastezone.$(ucr get domainname),cn=dns,$(ucr get ldap/base)" \ --set domain="wastezone.$(ucr get domainname)" * remove the fwdzone 'wastezone' # udm dns/forward_zone remove \ --dn zoneName="wastezone.$(ucr get domainname),$(ucr get ldap/base)" The result is quite what has been expected; the dnsFwdZone has been removed: #udm computers/ipmanagedclient list --filter cn=problem DN: cn=problem,cn=computers,dc=domain,dc=tld ARG: None domain: wastezone.domain.tld description: None ip: 192.168.2.3 mac: 00:11:22:33:44:56 name: problem network: cn=wastenet,cn=networks,dc=domain,dc=tld fqdn: problem.wastezone.domain.tld But the FQDN and the associatedDomain remains untouched. When now the network is changed, the associatedDomain still points to the removed fwdzone and so also the FQDN is simply wrong. # udm computers/ipmanagedclient modify \ --dn cn=problem,cn=computers,$(ucr get ldap/base) \ --set network=cn=default,cn=networks,$(ucr get ldap/base) #udm computers/ipmanagedclient list --filter cn=problem DN: cn=problem,cn=computers,dc=domain,dc=tld ARG: None domain: wastezone.domain.tld description: None ip: 192.168.2.3 mac: 00:11:22:33:44:56 name: problem network: cn=default,cn=networks,dc=domain,dc=tld fqdn: problem.wastezone.domain.tld This can only be fixed by setting the associatedDomain to the correct value: # udm computers/ipmanagedclient modify --dn "cn=problem,cn=computers,$(ucr get ldap/base)" --set domain="$(domainname)" # udm computers/ipmanagedclient list DN: cn=drucker-tech,cn=computers,dc=domain,dc=tld ARG: None domain: domain.tld description: None ip: 192.168.2.3 mac: 00:11:22:33:44:56 name: problem network: cn=default,cn=networks,dc=domain,dc=tld fqdn: drucker-tech.domain.tld ===== We should always adopt the associatedDomain to the assigned fwdzone, that will also fix the wrong PTR record in the rvszone.
Yes, the pointer records are not removed when removing a forward zone. Yes, the associated domain on all computer object if left untouched which is good I think. To reproduce this you also don't need to have a network object but it can be reproduced with plain setting of DNS forward / reverse zone. The behavior which happens if you are in the state of: * 1 computer object with accosicatedDomain=foobar * no forward zone foobar exists * a pointer record to $host.foobar exists → when opening the computer object and try to set another forward zone after clicking on "save" it seems to have worked but when opening the object again one sees that nothing happened and no forward zone is attached. One cannot set any forward zone anymore. Could you please also describe what problems this causes in nagios?
in Nagios the Host is shown as OFFLINE due to its not resolvable via dns, remember the FQDN is used to reach it.
This issue has been filed against UCS 4.2. UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.