4. Anfordererverhalten

4. Anfordererverhalten

Dieser Abschnitt beschreibt das Verhalten eines Anforderers, d.h. eines Agenten, der UPDATE-Anfragen stellt.

4.1. Ein Anforderer sendet eine UPDATE-Anfrage an einen bekannten autoritativen Nameserver für die zu aktualisierende Zone. Dieser Server kann ein primärer oder ein sekundärer Server für die Zone sein. Wenn der Server ein Slave ist, wird die Anfrage an den primären weitergeleitet. Der Anforderer kann mehrere Server ausprobieren, bevor er einen findet, der autoritativ ist und das Update durchführen kann.

4.2. Wenn der Server mit einem NOTAUTH- oder NOTIMP-Antwortcode antwortet, sollte der Anforderer einen anderen Server versuchen.

4.3. Wenn der Antwortcode SERVFAIL ist, sollte der Anforderer das Update wiederholen, möglicherweise nach einer gewissen Verzögerung. In Abwesenheit eines spezifischeren Wiederholungsalgorithmus, der durch ein DNS-Diensterkennungsprotokoll angegeben wird, sollte der Anforderer jedoch nicht unbegrenzt wiederholen.

4.4. Wenn der Antwortcode YXRRSET oder NXRRSET ist, bedeutet dies, dass die Voraussetzung nicht erfüllt wurde. Der Anforderer kann mit einer geänderten Voraussetzung wiederholen oder das Update abbrechen.

4.5. Wenn der Antwortcode NOERROR ist, wurde das Update vom primären Master akzeptiert. Dies garantiert jedoch nicht, dass alle Slaves das Update erhalten haben.

4.6. Ein Anforderer kann ein SOA RR in das Update aufnehmen, um SOA-Parameter festzulegen oder zu ändern. Wenn mehrere UPDATE-Nachrichten für dieselbe Zone nacheinander gesendet werden sollen und wenn das SOA SERIAL vom Anforderer verwaltet wird, sollte der Anforderer das aktuelle SOA SERIAL der Zone überprüfen (möglicherweise durch Überprüfung der Antwort auf ein vorheriges UPDATE), bevor nachfolgende Updates gesendet werden. Dies vermeidet Wettlaufsituationen zwischen den UPDATE-Nachrichten des Anforderers und Slave-Zonentransfers.

4.7. UDP wird für UPDATE-Anfragen bevorzugt, die in ein einzelnes Datagramm passen, da dies weniger Last auf dem Server und weniger Verzögerung für den Anforderer verursacht. Anforderer sollten jedoch bereit sein, die Anfrage mit TCP zu wiederholen, wenn die UDP-Anfrage abläuft, da einige Firewalls und Paketfilter UDP-Port 53 blockieren. Anforderer, die einen genauen Antwortcode benötigen, müssen TCP verwenden, da eine UDP-Antwort während der Übertragung verloren gehen kann.

4.8. Obwohl es möglich ist, mehrere Updates in eine einzelne UPDATE-Nachricht aufzunehmen, wird dies nicht empfohlen, es sei denn, die Updates sind stark miteinander verbunden. Der Grund dafür ist, dass, wenn ein Update in der Nachricht seine Voraussetzungen nicht erfüllt oder während der Verarbeitung auf einen Fehler stößt, die gesamte UPDATE-Nachricht abgelehnt wird. Daher sollten Anforderer im Allgemeinen separate UPDATE-Nachrichten für nicht zusammenhängende Updates senden.