4. Comportement du Demandeur
4. Comportement du Demandeur
Cette section décrit le comportement d'un demandeur, c'est-à-dire un agent effectuant des requêtes UPDATE.
4.1. Un demandeur envoie une requête UPDATE à un serveur de noms autoritaire connu pour la zone mise à jour. Ce serveur peut être un serveur principal ou esclave pour la zone. Si le serveur est un esclave, la requête sera transférée au principal. Le demandeur peut essayer plusieurs serveurs avant d'en trouver un qui soit autoritaire et puisse effectuer la mise à jour.
4.2. Si le serveur répond avec un code de réponse NOTAUTH ou NOTIMP, le demandeur devrait essayer un serveur différent.
4.3. Si le code de réponse est SERVFAIL, le demandeur devrait réessayer la mise à jour, peut-être après un certain délai. Cependant, en l'absence d'un algorithme de réessai plus spécifique spécifié par un protocole de découverte de service DNS, le demandeur ne devrait pas réessayer indéfiniment.
4.4. Si le code de réponse est YXRRSET ou NXRRSET, cela signifie que le prérequis n'a pas été satisfait. Le demandeur peut réessayer avec un prérequis modifié ou peut abandonner la mise à jour.
4.5. Si le code de réponse est NOERROR, la mise à jour a été acceptée par le maître principal. Cependant, cela ne garantit pas que tous les esclaves ont reçu la mise à jour.
4.6. Un demandeur peut inclure un RR SOA dans la mise à jour pour définir ou modifier les paramètres SOA. Si plusieurs messages UPDATE pour la même zone doivent être envoyés en séquence, et si le SOA SERIAL est géré par le demandeur, alors le demandeur devrait vérifier le SOA SERIAL actuel de la zone (peut-être en examinant la réponse à un UPDATE précédent) avant d'envoyer des mises à jour ultérieures. Cela évite les courses entre les messages UPDATE du demandeur et les transferts de zone esclave.
4.7. UDP est préféré pour les requêtes UPDATE qui tiennent dans un seul datagramme, car cela impose moins de charge sur le serveur et moins de délai pour le demandeur. Cependant, les demandeurs devraient être prêts à réessayer la requête en utilisant TCP si la requête UDP expire, car certains pare-feu et filtres de paquets bloquent le port UDP 53. Les demandeurs nécessitant un code de réponse précis doivent utiliser TCP, car une réponse UDP peut être perdue en transit.
4.8. Bien qu'il soit possible d'inclure plusieurs mises à jour dans un seul message UPDATE, cela n'est pas recommandé sauf si les mises à jour sont fortement liées. La raison en est que si une mise à jour dans le message ne satisfait pas ses prérequis ou rencontre une erreur pendant le traitement, le message UPDATE entier sera rejeté. Par conséquent, les demandeurs devraient généralement envoyer des messages UPDATE séparés pour les mises à jour non liées.