☰

Bind9: Master->Slave Benachrichtigen IPv6 mit Fallback auf IPv4

tag-icon • tag-icon bind ipv6 failover
Bind9: Master->Slave Benachrichtigen IPv6 mit Fallback auf IPv4

Ich habe ein kleines Master->Slave-DNS-Schema zwischen zwei Maschinen eingerichtet, auf denen Debian 8 + Bind9 im Dual-IP-Stack läuft.

Sowohl der Master als auch der Slave besitzen eine von Bind verwendete IPv4- und IPv6-Adresse, die durch die Konfigurationsparameter erzwungen wird listen-on listen-on-v6 transfer-source transfer-source-v6 notify-source notify-source-v6 query-source address query-source-v6 address.

Derzeit ist mein Master so eingestellt, dass er den Slave wie folgt benachrichtigt:

notify yes;
also-notify { xxxx:xxxx:xxxx:xxxx::xxx5; x.x.x.5; };

Da mein Slave eine Zonenkonfiguration hat, die ungefähr so ​​aussieht:

zone "example.dev" {
    type slave;
    masters { xxxx:xxxx:xxxx:xxxx::xxx2; x.x.x.2; };
    file "...";
};

Dieses Setup funktioniert einwandfrei. Allerdings zeigt die Überprüfung der Protokolldateien (wie von mir erwartet) an, dass der Master den Slave bei jedem Zonenwechsel zweimal benachrichtigt:

May 20 20:57:53 salvedns named[8568]: zone example.dev/IN: notify from x.x.x.2#52041: zone is up to date
May 20 20:57:53 salvedns named[8568]: zone example.dev/IN: notify from xxxx:xxxx:xxxx:xxxx::xxx2#51347: zone is up to date

Einmal über IPv4 und einmal über IPv6.

Gibt es eine Möglichkeit, dem Bind-Server mitzuteilen, dass es sich tatsächlich um Adressen für denselben DNS-Server handelt, und ihn zunächst über IPv6 zu benachrichtigen und es bei einem Fehler erneut über IPv4 zu versuchen? Und wie kann ich dasselbe mit der Salve- Deklaration xxxx:xxxx:xxxx:xxxx::xxx5 x.x.x.5machen ?masters

Danke schön.

Antwort1

Ich glaube nicht, dass es eine Konfigurationsoption gibt, die das tut, was Sie verlangen. Allerdings glaube ich auch nicht, dass die doppelten Benachrichtigungen wirklich Anlass zur Sorge geben.

Obwohl es in dieser Konfiguration redundant ist, ist der dadurch verursachte Mehraufwand minimal und stellt normalerweise überhaupt kein Problem dar.

Im Allgemeinen ist der Empfang mehrerer Benachrichtigungsnachrichten nicht ungewöhnlich, ursprünglich hauptsächlich von Master + anderen Slaves, jetzt aber auch von Dual-Stack-Hosts, bis zu dem Punkt, an dem sogardie ursprüngliche Spezifikation erwartete dies:

4.2. Jeder Slave erhält wahrscheinlich mehrere Kopien derselben NOTIFY-Anfrage: Eine vom primären Master und eine von jedem anderen Slave, während dieser die neue Zone überträgt und seine potenziellen Peers benachrichtigt. Das NOTIFY-Protokoll unterstützt diese Vielfalt, indem es verlangt, dass NOTIFY von einem Slave/Master erst gesendet wird, NACHDEM er den SOA RR aktualisiert hat oder festgestellt hat, dass keine Aktualisierung erforderlich ist, was in der Praxis nach einer erfolgreichen Zonenübertragung bedeutet. Wenn also keine Neuordnung der Zustellung erfolgt, ist die letzte NOTIFY, die ein Slave erhält, diejenige, die die letzte Änderung anzeigt. Da ein Slave SOAs und AXFR/IXFRs immer nur von seinen bekannten Mastern anfordert, hat er die Möglichkeit, seine QUERY für die SOA zu wiederholen, nachdem jeder seiner Master jede Zonenaktualisierung abgeschlossen hat.

verwandte Informationen