5. Comportement de Transfert

5. Comportement de Transfert

Cette section décrit le comportement d'un serveur de transfert, c'est-à-dire un serveur de noms esclave qui transfère les requêtes UPDATE au maître principal.

5.1. Lorsqu'un serveur esclave reçoit une requête UPDATE pour une zone pour laquelle il est autoritaire, il devrait transférer la requête au maître principal pour cette zone. L'adresse du maître principal devrait être obtenue à partir du champ SOA MNAME de la zone ou de la configuration du serveur.

5.2. Le serveur esclave devrait préserver l'adresse du demandeur d'origine et les autres paramètres de requête lors du transfert de la requête. Cela permet au maître principal d'appliquer des politiques de sécurité et d'envoyer la réponse directement au demandeur d'origine.

5.3. Si le serveur esclave utilise UDP pour transférer la requête, il devrait être prêt à réessayer en utilisant TCP si la requête UDP expire ou s'il reçoit un bit TC (troncature) dans la réponse.

5.4. Si un serveur esclave reçoit une requête UPDATE via TCP, il DOIT transférer la requête au maître principal en utilisant TCP. Cela garantit que les demandeurs nécessitant des codes de réponse précis (c'est pourquoi ils ont utilisé TCP en premier lieu) les recevront.

5.5. Un serveur esclave peut implémenter un mécanisme de délai de transfert. Si une requête transférée ne reçoit pas de réponse du maître principal dans cette période de délai, l'esclave peut renvoyer une réponse SERVFAIL au demandeur d'origine et fermer la connexion (si TCP a été utilisé).

5.6. Si le serveur esclave est incapable de transférer la requête (par exemple, parce qu'il ne peut pas se connecter au maître principal), il devrait renvoyer une réponse SERVFAIL au demandeur.

5.7. Il est possible qu'un serveur esclave implémente une chaîne de transfert, où les mises à jour sont transférées à travers plusieurs serveurs esclaves avant d'atteindre le maître principal. Cependant, de telles configurations ne sont pas recommandées car elles introduisent des points de défaillance et des délais supplémentaires. Si une telle configuration est utilisée, chaque serveur de transfert dans la chaîne devrait suivre les règles décrites dans cette section.

5.8. Un serveur de transfert ne devrait pas modifier le message UPDATE sauf si nécessaire pour le transfert de message DNS (par exemple, définir le bit de récursion souhaitée comme approprié pour sa configuration).

5.9. Le serveur de transfert peut mettre en cache l'adresse du maître principal pour éviter des recherches SOA MNAME répétées. Cependant, il devrait être prêt à actualiser ce cache si les tentatives de transfert échouent, car le maître principal peut avoir été déplacé.

5.10. Si une boucle de transfert est détectée (par exemple, si le serveur esclave reçoit sa propre requête transférée en retour), le serveur devrait renvoyer SERVFAIL pour éviter les boucles de transfert infinies.