Univention Bugzilla – Bug 28367
UDM modue DNS doesn't check for collisions between CNAME and aRecord
Last modified: 2020-03-05 12:16:32 CET
An Ticket#: 2012082421000932 wurden zwischen univention-bind (Port 7777) und univention-bind-proxy (Port 53) und keine Zonen-Transfers merh durchgeführt. Im syslog fanden sich Meldungen folgender Art: ========================================================================== Aug 29 15:04:42 master named[5727]: received control channel command 'reload domain.example.com' Aug 29 15:04:42 master named[3406]: received control channel command 'reload domain.example.com' Aug 29 15:04:42 master named[3406]: zone domain.example.com/IN: Transfer started. Aug 29 15:04:42 master named[3406]: transfer of 'domain.example.com/IN' from 127.0.0.1#7777: connected using 127.0.0.1#43735 Aug 29 15:04:42 master named[5727]: client 127.0.0.1#43735: transfer of 'domain.example.com/IN': AXFR started Aug 29 15:04:42 master named[5727]: client 127.0.0.1#43735: transfer of 'domain.example.com/IN': AXFR ended Aug 29 15:04:42 master named[3406]: transfer of 'domain.example.com/IN' from 127.0.0.1#7777: failed while receiving responses: CNAME and other data Aug 29 15:04:42 master named[3406]: transfer of 'domain.example.com/IN' from 127.0.0.1#7777: Transfer completed: 0 messages, 102 records, 0 bytes, 0.303 secs (0 bytes/sec) ========================================================================== Die Meldung "failed while receiving responses: CNAME and other data" wies darauf hin, dass eine Überschneidung zwischen einem CNAME/Alias-Record und einem anderen Record vorlag. Ursache waren folgende Records: relativeDomainName=sys1,zoneName=domain.example.com,$ldap_base objectClass: dNSZone aRecord: 10.200.8.10 relativeDomainName=sys1,cn=subcontainer,zoneName=domain.example.com,$ldap_base objectClass: dNSZone cNAMERecord: foo.bar.org Das UDM Modul DNS sollte solche Überschneidungen innerhalb einer Zone beim Anlegen von Records prüfen.
Beobachtet unter UCS 2.4, wahrscheinlich auch vorhanden unter UCS 3.x.
This issue has been filed against UCS 2.4. UCS 2.4 is out of maintenance and many UCS components have vastly 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". In this case please provide detailed information on how this issue is affecting you.
REOPEN?
Happened again and the colliding records are hard to see because it's not logged. If this happens again: dig axfr @127.0.0.1 "$(dnsdomainname)" -p 7777 > zonedata.txt named-checkzone "$(dnsdomainname)" zonedata.txt
This caused the zone transfer from univention-bind-ldap to bind9 to fail on an UCS slave in a customer's domain. Since working DNS on slaves is a key scenario and finding the problematic record and corresponding LDAP object is not trivial, I'd like to increase the pain.
Another customer stumbling into this issue and causing a support ticket. I could easily reproduce through UMC by: 1. Create a CNAME record for badname pointing to whatever value 2. Create a A record for badname.multi.ucs. pointing to an IP (Note: UMC prevents using the same short name but allows adding an zone where it is not neccessary!) Wait for sync and then go to a host with dns/backend=ldap. Restart bind9 (systemctl). You will notice the entries in /var/log/syslog: ================================================================== Mar 5 12:11:47 slave named[46627]: transfer of 'multi.ucs/IN' from 127.0.0.1#7777: failed while receiving responses: CNAME and other data Mar 5 12:11:47 slave named[46627]: transfer of 'multi.ucs/IN' from 127.0.0.1#7777: Transfer status: CNAME and other data ================================================================== And the local nameserver is not able to resolve its own domain! Suggested solution: Change UMC to strip the domainname from all records in the zone before accepting the entry. Thus, duplicate entries as above will not happen!