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?
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?
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,
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:
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.