Bind zone refresh schlägt fehl

Hallo in die Runde,

wir beobachten gerade ein merkwürdiges Phänomen in unserer UCS4.1 Umgebung. Es sind 3 Server in Betrieb: 1 DC-Master und 2 DC-Slaves. Die beiden DC Slaves sind für die lokale Namensauflösung verantwortlich und laufen mit univention-bind.

Nun kommt es in der Umgebung zu Problemen mit der Übertragung der DNS Zone unseres Intranets. Merkwürdig daran erscheint mir, das bind auf dem DC-Master ohne Probleme läuft. Die Zone-Caches werden in /var/cache/bind/ angelegt und die Namensauflösung klappt. Auch ein Syntax Check klappt fehlerfrei:

named-checkzone haupt.zone.de /var/cache/bind/haupt.zone.de.zone zone haupt.zone.de/IN: loaded serial 1342 OK
Ich gehe daher davon aus, das der Fehler nicht im LDAP zu suchen ist.

Auf beiden DC-Slaves bekommen wir nach der kleinsten Änderung an den DNS-Einstellungen der Host Objekte (z.B.: alias anlegen, alten Host entfernen usw.) einen Fehler:

Nach dem reload von bind

Jul 11 10:47:36 server2 named[2717]: command channel listening on 127.0.0.1#55555 Jul 11 10:47:36 server2 named[2717]: zone haupt.zone.de/IN: NS 'dc.haupt.zone.de' has no address records (A or AAAA) Jul 11 10:47:36 server2 named[2717]: zone haupt.zone.de/IN: NS 'server1.haupt.zone.de' has no address records (A or AAAA) Jul 11 10:47:36 server2 named[2717]: zone haupt.zone.de/IN: NS 'server2.haupt.zone.de' has no address records (A or AAAA) Jul 11 10:47:36 server2 named[2717]: zone haupt.zone.de/IN: not loaded due to errors. Jul 11 10:47:36 server2 named[2717]: managed-keys-zone ./IN: loaded serial 0

und weiter unten dann schließlich:

zone haupt.zone.de/IN: refresh: unexpected rcode (SERVFAIL) from master 127.0.0.1#7777 (source 0.0.0.0#0)

Das Zone Cache File in /var/cache/bind/ wird entfernt und die Namensauflösung ist dahin. Bisher konnten wir das Problem nur mit einem kompletten Join der Slaves umschiffen. Sobald jedoch ein Rechnerobjekt über die UMC verändert wird, schmiert die Zone ab.

Gibt es noch einen anderen Weg, die Konsistenz der DNS Datenbanken zu prüfen?

lG

Sebastian

Hallo,

ich bin heute - ebenfalls auf der Suche nach einer Lösung für ein ähnliches Problem - über [bug]40497[/bug] gestolpert.

Wichtig wäre aus meiner Sicht auf jeden Fall noch die Information, welches DNS-Backend (UCRV dns/backend) in Benutzung ist.

Viele Grüße,
Dirk Ahrnke

Guten Abend Herr Ahrnke,

vielen Dank für Ihre Hinweise. Das DNS/Backend ist LDAP. Der Bug könnte also zutreffend sein. Ich bin noch die Hinweise im SDB Eintrag: http://sdb.univention.de/content/20/254/en/bind-zone-transfer-failed.html durchgegangen, habe aber auf die Schnelle nichts konkretes finden können.

Die Einzige Änderung, die wir unabhängig von DNS auf dem DC vorgenommen hatten, war das Einrichten einer Cool Solution:

wiki.univention.de/index.php?tit … nformation

Könnte es sein, das der LDAP-Server auf den DC-Slaves durch die veränderten ACLs durcheinanderkommt?

lG

Sebastian

Inzwischen habe ich herausgefunden, das das Zonefile scheinbar keine Fehler enthält. Allerdings ist der LDAP Datenbestand inkonsitent. Im LDAP der Slave-DC taucht die entsprechende Zone gar nicht auf, bzw. ist leer. Im LDAP auf dem Master-DC ist sie dagegen vollständig vorhanden.

Trotz des fehlenden Eintrags, ist kein Fehler in der Replikation sichtbar. Aber eigentlich sollten doch derartige Inkonsistenzen zu einer Fehlermeldung im Replication Log führen, oder?

lG
Sebastian

Ich würde auch erwarten, dass Replikationsfehler im Log zu sehen sind.
Im konkreten Fall sollte ein erneuter Join des/der Slaves das Problem erstmal beheben,

Hallo nochmal in die Runde,

wir konnten den Fehler nun beheben. Der Fokus unserer Untersuchungen lag auf den beteiligten Slave-DC Servern. Ein Blick in das Logfile listener.log auf dem DC brachte den entscheidenden Hinweis:

09.05.16 11:12:31.015 LISTENER ( WARN ) : handler: replication (failed) 09.05.16 11:12:31.114 LISTENER ( WARN ) : at least one delete handler failed

Nachdem resync des entsprechenden handler klappte auch die Replikation auf den Slave-DC Servern. Der Befehl auf dem DC lautete:

univention-directory-listener-ctrl resync replication

Wenn ich das richtig verstehe, wird die Replikation lediglich anhand der Listener/Notifier ID überprüft. In unserem Fall wurden diese IDs auf den beteiligten System wie erwartet hochgezählt. Allerdings war der Datenbestand des LDAP selbst ganz offensichtlich inkonsistent. Gibt es eine Möglichkeit die Konsistenz des LDAP Datenbestandes auf den beteiligten Servern zu prüfen?

Mit den besten Grüßen und Danke für die hilfreichen Hinweise.

Sebastian