Bug 37086 - After deleting a DC slave object the DNS is not updated anymore
After deleting a DC slave object the DNS is not updated anymore
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC - Computers
UCS 3.2
Other Linux
: P5 normal (vote)
: UCS 4.1-3-errata
Assigned To: Felix Botner
Stefan Gohmann
:
Depends on:
Blocks: 42396
  Show dependency treegraph
 
Reported: 2014-11-27 12:06 CET by Sönke Schwardt-Krummrich
Modified: 2016-10-05 14:59 CEST (History)
7 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
53_remove_ns_record_from_removed_computers (1.63 KB, text/plain)
2015-01-15 14:23 CET, Florian Best
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sönke Schwardt-Krummrich univentionstaff 2014-11-27 12:06:26 CET
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.
Comment 1 Sönke Schwardt-Krummrich univentionstaff 2014-11-27 12:07:41 CET
Sidenote: this problem may also occur with other system roles (especially DC backup).
Comment 2 Florian Best univentionstaff 2015-01-15 14:23:29 CET
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.
Comment 3 Florian Best univentionstaff 2015-01-15 15:40:28 CET
This happens also when we rename the computer object.

What about MX records? They are also untouched. Should they be modified, too?
Comment 4 Philipp Hahn univentionstaff 2015-11-18 09:38:35 CET
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
Comment 5 Philipp Hahn univentionstaff 2016-01-12 14:11:57 CET
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.
Comment 6 Michael Grandjean univentionstaff 2016-01-12 14:31:32 CET
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"
Comment 7 Christina Scheinig univentionstaff 2016-03-30 09:17:04 CEST
Happened again at Ticket#2016032921000274
Comment 8 Florian Best univentionstaff 2016-07-08 13:16:50 CEST
*** Bug 27436 has been marked as a duplicate of this bug. ***
Comment 9 Felix Botner univentionstaff 2016-08-25 13:30:40 CEST
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
Comment 10 Florian Best univentionstaff 2016-08-25 13:54:49 CEST
(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
Comment 11 Stefan Gohmann univentionstaff 2016-09-07 07:49:36 CEST
Code review: OK

ucs-test: OK

Tests: OK

YAML: OK
Comment 12 Janek Walkenhorst univentionstaff 2016-09-07 18:41:35 CEST
<http://errata.software-univention.de/ucs/4.1/243.html>