5. Weiterleitungsverhalten
5. Weiterleitungsverhalten
Dieser Abschnitt beschreibt das Verhalten eines Weiterleitungsservers, d.h. eines Slave-Nameservers, der UPDATE-Anfragen an den primären Master weiterleitet.
5.1. Wenn ein Slave-Server eine UPDATE-Anfrage für eine Zone erhält, für die er autoritativ ist, sollte er die Anfrage an den primären Master für diese Zone weiterleiten. Die Adresse des primären Masters sollte aus dem SOA MNAME-Feld der Zone oder aus der Serverkonfiguration abgerufen werden.
5.2. Der Slave-Server sollte die Adresse des ursprünglichen Anforderers und andere Anfrageparameter beim Weiterleiten der Anfrage bewahren. Dies ermöglicht es dem primären Master, Sicherheitsrichtlinien anzuwenden und die Antwort direkt an den ursprünglichen Anforderer zu senden.
5.3. Wenn der Slave-Server UDP zum Weiterleiten der Anfrage verwendet, sollte er bereit sein, mit TCP zu wiederholen, wenn die UDP-Anfrage abläuft oder wenn er ein TC-Bit (Truncation) in der Antwort erhält.
5.4. Wenn ein Slave-Server eine UPDATE-Anfrage über TCP erhält, MUSS er die Anfrage über TCP an den primären Master weiterleiten. Dies stellt sicher, dass Anforderer, die genaue Antwortcodes benötigen (weshalb sie TCP verwendet haben), diese erhalten.
5.5. Ein Slave-Server kann einen Weiterleitungs-Timeout-Mechanismus implementieren. Wenn eine weitergeleitete Anfrage innerhalb dieser Timeout-Periode keine Antwort vom primären Master erhält, kann der Slave eine SERVFAIL-Antwort an den ursprünglichen Anforderer zurückgeben und die Verbindung schließen (wenn TCP verwendet wurde).
5.6. Wenn der Slave-Server die Anfrage nicht weiterleiten kann (z.B. weil er keine Verbindung zum primären Master herstellen kann), sollte er eine SERVFAIL-Antwort an den Anforderer zurückgeben.
5.7. Es ist möglich, dass ein Slave-Server eine Kette von Weiterleitungen implementiert, bei der Updates über mehrere Slave-Server weitergeleitet werden, bevor sie den primären Master erreichen. Solche Konfigurationen werden jedoch nicht empfohlen, da sie zusätzliche Fehlerpunkte und Verzögerungen einführen. Wenn eine solche Konfiguration verwendet wird, sollte jeder Weiterleitungsserver in der Kette den in diesem Abschnitt beschriebenen Regeln folgen.
5.8. Ein Weiterleitungsserver sollte die UPDATE-Nachricht nicht ändern, außer soweit dies für die DNS-Nachrichtenweiterleitung erforderlich ist (z.B. Setzen des Recursion Desired-Bits entsprechend seiner Konfiguration).
5.9. Der Weiterleitungsserver kann die Adresse des primären Masters zwischenspeichern, um wiederholte SOA MNAME-Lookups zu vermeiden. Er sollte jedoch bereit sein, diesen Cache zu aktualisieren, wenn Weiterleitungsversuche fehlschlagen, da der primäre Master möglicherweise verschoben wurde.
5.10. Wenn eine Weiterleitungsschleife erkannt wird (z.B. wenn der Slave-Server seine eigene weitergeleitete Anfrage zurückerhält), sollte der Server SERVFAIL zurückgeben, um unendliche Weiterleitungsschleifen zu vermeiden.