Der BIND-Slave wird erst nach einem Neustart mit dem Master synchronisiert

Ich habe zwei DNS-Server mit BIND9, einen Master und einen Slave. Wenn die Zonendatei auf dem Master aktualisiert wird, möchte ich, dass der Slave-Server sofort mit der Bereitstellung der geänderten Datensätze beginnt, aber BIND gibt mir ein wenig Ärger.

Die DNS-Zonenübertragung zwischen Master und Slave funktioniert bereits ordnungsgemäß. Ich kann mich beim Slave-Server anmelden und ausführen dig @dnsmaster myzone. AXFRund er druckt den gesamten Inhalt der Zone aus. Damit dies funktioniert, ist der DNS-Master mit notify yesund konfiguriert also-notify { dnsslave }. Ebenso ist der Slave mit konfiguriert allow-transfer { dnsmaster }.

Wenn dnsmaster aktualisiert wird, werde ich ausgeführt rndc reloadund es wird mir mitgeteilt, dass Benachrichtigungen gesendet werden. Dies wird auf dem Slave durch Überprüfen der Zonendateien in bestätigt /var/named/slavedata/. Sie enthalten die neuesten Daten, die dem entsprechen, was der Master weiß.

Jetzt kommt der seltsame Teil.

Der Slave-Server stellt weiterhin alte, veraltete DNS-Einträge bereit und ignoriert vollständig die Tatsache, dass neue Daten auf der Festplatte verfügbar sind, nachdem sie vom Master benachrichtigt wurden. Ich verwende dig, um die Ergebnisse mit diesem Befehl zu überprüfen : dig @slaveserver record.zone.tld.

Ich dachte, BIND könnte einen In-Memory-Cache seiner autorisierenden Zonen behalten, also habe ich max-cache-sizeund max-cache-ttlauf 0 gesetzt, aber das hatte keine Auswirkung.

Ich habe versucht, diesen angeblichen Cache auf andere Weise zu leeren, indem ich Befehle wie rndc flushund rndc reloadauf dem Slave-Server ausgeführt habe, aber es werden immer noch die alten veralteten Datensätze zurückgegeben.

Schließlich bemerkte ich, dass MINTTLin der Zone 86400 (24 Stunden) eingestellt war, also änderte ich vorübergehend die MINTTLauf 15 Sekunden und startete den Slave-Server neu. Keine Auswirkung - Der Slave würde erst nach dem Neustart des Dienstes aktualisierte DNS-Ergebnisse bereitstellen.

Was ist denn hier los? Was ist das erwartete Verhalten von BIND9 beim Empfang einer Benachrichtigung, dass eine Zone aktualisiert wird? Respektiert es immer TTLund MINTTL? Ich würde davon ausgehen, dass immer die neuesten verfügbaren Daten verwendet werden.

Am Ende meines Witzes denke ich darüber nach, eine Crontab einzurichten, um die BIND-Slaves stündlich neu zu starten, um zu vermeiden, dass veraltete Daten bereitgestellt werden. Gibt es etwas Besseres?

Aus Ihrer Beschreibung kann ich Ihnen nicht genau sagen , was ist das Problem aber ich kann Ihnen mehrere Dinge ausschließen helfen.

Die Einstellungen für die Cache-Größe und die Cache-TTL gelten für zwischengespeicherte rekursive Abfragedaten und gelten (wie Sie bereits vermutet haben) nicht für autorisierende Daten. Ebenso ist rndc flush hier nicht anwendbar.

Vorgeschlagene Methode zur Fehlerbehebung:

1. Stellen Sie sicher, dass die Benachrichtigungsnachrichten wie erwartet vom Master gesendet werden. Überprüfen Sie die Protokolle und / oder den Datenverkehr zwischen Master und Slave.
2. Überprüfen Sie anhand der Protokolle, ob die Benachrichtigungsnachricht vom Slave empfangen wird.
3. Wenn Sie nicht sehen können, dass der Slave die Benachrichtigung empfängt, beheben Sie das Problem als Benachrichtigungsproblem. Überprüfen Sie daher Ihre Benachrichtigungsoptionen in der Datei named.conf auf dem Master, um sicherzustellen, dass sie wie erwartet definiert sind, später nicht überschrieben werden und einen angemessenen Gültigkeitsbereich haben. Ich empfehle die Verwendung von "explizit benachrichtigen". mit "also-notify {Slave-Server;};"
4. Wenn der Slave ist zu sehen , die mitteilen, Ihr Problem ist , herauszufinden , warum Datei der Zone nicht aktualisiert wird, wie Sie es erwarten. Was sollte geschehen ist , nachdem der empfangen wird benachrichtigt, soll der Slave eine SOA - Abfrage machen, zu vergleichen , zu seinen aktuellen SOA, und tut eine AXFR (oder IXFR , wenn Sie es aktiviert haben) die aktualisierte Zone Kopie (vorausgesetzt , die SOA auf dem Master zu bekommen ist höher.) Sie sollten in der Lage sein, all dies mit einem Sniffer zu beobachten, und Sie sollten auch Beweise dafür in den Protokollen auf beiden Servern sehen.
5. Wenn die Vorgänge nicht wie erwartet ausgeführt werden, vergleichen Sie zunächst manuell die SOA-Seriennummern auf den beiden Servern (dig @server $ zonename SOA), um sicherzustellen, dass Sie dem Slave nicht versehentlich eine höher als erwartete Seriennummer gegeben haben in der Vergangenheit, die jetzt höher ist als die Seriennummer des Masters.

Wenn dies nicht funktioniert, sollten Sie weitere Informationen veröffentlichen, einschließlich der Abschnitte named.conf sowohl vom Master als auch vom Slave und Protokolle von beiden Servern darüber, was nach dem Laden einer frisch bearbeiteten Zone auf dem Master geschieht.

Ich sah mich der gleichen Situation gegenüber. Meine Nachforschungen führten mich zu folgender Erkenntnis. Wenn Sie Ansichten verwenden, dient dig @ local machine nur dem, was in der localhost-Ansicht enthalten ist. Die localhost-Ansicht wird nur beim Neustart des genannten aktualisiert. Die neueste Zonendatei (vom Master übertragen) ist jedoch weiterhin auf dem Slave verfügbar und wird für alle Abfragen bereitgestellt, die von externen Quellen oder externen Ansichten stammen. Sie müssen also Vorkehrungen treffen, damit Ihre lokale Host-Ansicht aktualisiert wird.

Vergessen Sie nicht, die Serien-ID aus den Zonendateien zu erhöhen, wenn Sie Änderungen in Master Server vornehmen, bevor Sie den Namen neu laden. Andernfalls werden die Zonendateien nicht auf Slave Server repliziert.