A joined DC slave object (cn=slave42) has been removed from LDAP (also all referring objects). But at forward and reverse zones the nSRecord attributes do not get updated during removal → the entry "nSRecord: slave42.nstx.local." is not removed. # nstx.local, dns, nstx.local dn: zoneName=nstx.local,cn=dns,dc=nstx,dc=local objectClass: top objectClass: dNSZone objectClass: univentionObject univentionObjectType: dns/forward_zone dNSTTL: 10800 relativeDomainName: @ zoneName: nstx.local nSRecord: master40.nstx.local. nSRecord: slave42.nstx.local. nSRecord: backup41.nstx.local. sOARecord: master40.nstx.local. root.nstx.local. 22 28800 7200 604800 10800 Because of this, the DNS server is not able to update its zones, e.g. triggered via listener module: root@master40:~# rndc -p 55555 reload nstx.local rndc: 'reload' failed: bad zone root@master40:~# tail -n3 /var/log/syslog Nov 27 00:28:36 master40 named[2477]: received control channel command 'reload nstx.local' Nov 27 00:28:36 master40 named[2477]: zone nstx.local/IN: NS 'slave42.nstx.local' has no address records (A or AAAA) Nov 27 00:28:36 master40 named[2477]: zone nstx.local/IN: not loaded due to errors. This has been reproduced on a second system, where only the forward zone was affected. On the first system, 3 orphaned DNS entries were found in the DNS forward AND reverse zones.
Sidenote: this problem may also occur with other system roles (especially DC backup).
Created attachment 6605 [details] 53_remove_ns_record_from_removed_computers Attached a ucs-test script which tests reverse and forward zones for the nameserver entry after a DC slave was removed.
This happens also when we rename the computer object. What about MX records? They are also untouched. Should they be modified, too?
Still a problem with UCS-4.0-4 # dig +nostats +noqr +nocmd +nocomments -t ns $(dnsdomainname) ;phahn.qa. IN NS phahn.qa. 10800 IN NS backup40.phahn.qa. phahn.qa. 10800 IN NS master40.phahn.qa. master40.phahn.qa. 80600 IN A 10.200.17.26
When a DC is removed with "remove referring" enabled, the A/AAA/PTR DNS records are deleted, but the NS record stays behind: # udm computers/domaincontroller_slave remove --remove_referring --dn cn=sla30,cn=dc,cn=computers,dc=phahn,dc=qa Object removed: cn=sla30,cn=dc,cn=computers,dc=phahn,dc=qa # udm computers/domaincontroller_slave remove --remove_referring --dn cn=sla41,cn=dc,cn=computers,dc=phahn,dc=qa Object removed: cn=sla41,cn=dc,cn=computers,dc=phahn,dc=qa # udm dns/forward_zone list DN: zoneName=phahn.qa,cn=dns,dc=phahn,dc=qa ARG: None ... nameserver: master41.phahn.qa. nameserver: slave41.phahn.qa. nameserver: sla41.phahn.qa. /usr/lib/univention-install/05univention-bind.inst: 87 # Append local server as DNS server to the zones 88 zone="$(udm dns/forward_zone list "$@" --filter "(&(zone=$domainname)(!(nameserver=${hostname}.${domainname}.)))" | sed -ne 's|DN: ||p')" 89 if [ -n "$zone" ]; then 90 udm dns/forward_zone modify "$@" --dn "$zone" --append nameserver="${hostname}.${domainname}." 91 fi 92 93 zone="$(udm dns/reverse_zone list "$@" --filter "(&(subnet=$reversezone)(!(nameserver=${hostname}.${domainname}.)))" | sed -ne 's|DN: ||p')" 94 if [ -n "$zone" ]; then 95 udm dns/reverse_zone modify "$@" --dn "$zone" --append nameserver="${hostname}.${domainname}." 96 fi This should be un-done if the server is removed: either UDM could be extended to do some more "reffering" updates or a listener module on the master could trigger an update of the DNS zones when a DC is removed. There should also be a (diagnostic) test to assert all mentioned servers are known.
This is quite annoying and lead to the problem mentioned in Bug 40393: 1. UCS Slave was installed as "owncloud.example.org" 2. UCS Slave was deleted 3. UCS Slave was installed as "owncloud01.example.org" 4. A DNS alias "owncloud.example.org" was created for "owncloud01.example.org"
Happened again at Ticket#2016032921000274
*** Bug 27436 has been marked as a duplicate of this bug. ***
simpleComputer.cleanup() now also removes the fqdn from the forward/reverse zones of the computer object (only if at least one other nameserver is set, zone objects require the nameserver attribute). (In reply to Florian Best from comment #3) > This happens also when we rename the computer object. Renaming computer objects is not longer allowed. > What about MX records? They are also untouched. Should they be modified, too? no, create a new bug if this is important Added test 66_udm-computers/55_nameserver_update_in_zone_on_delete * univention-directory-manager-modules.yaml 11.0.3-31.1420.201608251310 * merge to 4.2-0
(In reply to Felix Botner from comment #9) > simpleComputer.cleanup() now also removes the fqdn from the forward/reverse > zones of the computer object (only if at least one other nameserver is set, > zone objects require the nameserver attribute). > > (In reply to Florian Best from comment #3) > > This happens also when we rename the computer object. > Renaming computer objects is not longer allowed. That's true for DC Master/Backup/Slave/Member but not for Windows DC/Windows/Ubuntu/Linux/UCC/MacOS/Trustaccount/IP Managed Client. > > What about MX records? They are also untouched. Should they be modified, too? > no, create a new bug if this is important Yes it is, Bug #42125
Code review: OK ucs-test: OK Tests: OK YAML: OK
<http://errata.software-univention.de/ucs/4.1/243.html>