4. Transport

Cette section décrit les exigences du protocole de transport pour AXFR. La spécification DNS originale définissait AXFR pour fonctionner sur TCP, et cela reste le seul transport standardisé pour AXFR.

4.1. TCP

AXFR DOIT utiliser TCP comme protocole de transport. TCP fournit une livraison de données fiable, ordonnée et vérifiée contre les erreurs, ce qui est essentiel pour l'intégrité des transferts de zone.

4.1.1. TCP du client AXFR

Un client AXFR établit une connexion TCP vers le port DNS du serveur AXFR (typiquement le port 53, bien que d'autres ports PUISSENT être configurés).

Établissement de connexion :

1. Le client AXFR initie la poignée de main TCP en trois étapes pour établir une connexion avec le serveur AXFR.

2. Une fois la connexion TCP établie, le client AXFR envoie le message de requête AXFR comme spécifié dans la Section 2.1.

3. Le client AXFR attend ensuite que le serveur AXFR réponde avec un ou plusieurs messages de réponse DNS contenant les données de zone.

Persistance de connexion :

1. Le client AXFR DEVRAIT maintenir la connexion TCP ouverte jusqu'à ce que le transfert de zone complet soit reçu, comme indiqué par la réception du RR SOA final dans la section de réponse d'un message de réponse.

2. Après avoir reçu le transfert de zone complet, le client AXFR PEUT fermer la connexion TCP ou PEUT la maintenir ouverte pour envoyer des requêtes supplémentaires (bien que ce ne soit pas un comportement typique pour AXFR).

3. Le client AXFR DOIT être préparé à ce que le serveur AXFR ferme la connexion TCP à tout moment, y compris immédiatement après avoir terminé le transfert de zone.

Délais d'attente :

1. Le client AXFR DEVRAIT implémenter des délais d'attente de lecture et d'écriture pour détecter des serveurs qui ne répondent pas ou des problèmes de réseau.

2. Les valeurs de délai d'attente recommandées varient en fonction de la taille de la zone et des conditions du réseau, mais un délai d'attente de lecture typique pourrait être de l'ordre de minutes (par exemple, 5-10 minutes) pour accommoder les grandes zones.

3. Si un délai d'attente se produit, le client AXFR DEVRAIT fermer la connexion TCP et traiter le transfert de zone comme ayant échoué.

Gestion des erreurs :

1. Si le client AXFR reçoit un message de réponse DNS avec un RCODE autre que NOERROR, il DOIT traiter le transfert de zone comme ayant échoué et fermer la connexion TCP.

2. Si le client AXFR reçoit un message DNS mal formé ou un message qui ne se conforme pas au protocole AXFR, il DEVRAIT fermer la connexion TCP et traiter le transfert de zone comme ayant échoué.

3. Si la connexion TCP est fermée prématurément (avant que le RR SOA final soit reçu), le client AXFR DOIT traiter le transfert de zone comme ayant échoué et rejeter toutes données de zone partielles reçues.

Requêtes multiples :

1. Un client AXFR PEUT envoyer plusieurs requêtes AXFR sur la même connexion TCP, une pratique connue sous le nom de "pipelining" ou "réutilisation de connexion". Cependant, ce comportement n'est pas largement implémenté ou requis.

2. Si un client AXFR envoie plusieurs requêtes, il DOIT attendre la réponse complète à la première requête (y compris le RR SOA final) avant d'envoyer la requête suivante.

3. Un serveur AXFR n'est pas tenu de prendre en charge plusieurs requêtes par connexion et PEUT fermer la connexion après avoir répondu à une seule requête.

4.1.2. TCP du serveur AXFR

Un serveur AXFR écoute les connexions TCP entrantes sur son port DNS (typiquement le port 53).

Gestion de connexion :

1. Après avoir accepté une connexion TCP, le serveur AXFR attend de recevoir un message de requête DNS du client AXFR.

2. Le serveur AXFR analyse le message de requête pour déterminer s'il s'agit d'une requête AXFR valide (comme défini dans la Section 2.1).

3. En fonction de la requête et des politiques applicables (par exemple, ACL, authentification TSIG), le serveur AXFR répond soit avec les données de zone, soit avec un message d'erreur.

Transmission de réponse :

1. Si le transfert de zone est autorisé, le serveur AXFR envoie un ou plusieurs messages de réponse DNS contenant les données de zone, comme spécifié dans la Section 2.2.

2. Chaque message de réponse est envoyé en tant que message DNS complet sur la connexion TCP. Le serveur AXFR DOIT s'assurer que les limites de message sont préservées (c'est-à-dire, chaque message DNS est précédé d'un champ de longueur de 2 octets, comme spécifié dans RFC 1035 Section 4.2.2).

3. Le serveur AXFR continue d'envoyer des messages de réponse jusqu'à ce que toutes les données de zone (y compris le RR SOA final) aient été transmises.

Terminaison de connexion :

1. Après avoir transmis le message de réponse final (contenant le RR SOA final), le serveur AXFR PEUT fermer la connexion TCP immédiatement ou PEUT la maintenir ouverte pour accepter des requêtes supplémentaires.

2. Le serveur AXFR DEVRAIT fermer les connexions inactives après une période de délai d'attente raisonnable pour libérer des ressources.

3. Le serveur AXFR PEUT fermer la connexion à tout moment si une erreur se produit (par exemple, une erreur d'écriture, un délai d'attente ou une erreur interne).

Concurrence :

1. Un serveur AXFR DEVRAIT être capable de gérer plusieurs sessions AXFR simultanées (c'est-à-dire, plusieurs connexions TCP de différents clients).

2. Le serveur AXFR PEUT imposer des limites sur le nombre de transferts de zone simultanés pour éviter l'épuisement des ressources.

4.2. UDP

AXFR sur UDP n'est pas standardisé et NE DOIT PAS être utilisé dans les implémentations DNS à usage général. Bien que les premières spécifications DNS mentionnaient la possibilité d'AXFR sur UDP pour les petites zones, cette approche présente des limitations importantes :

1. Fiabilité : UDP est un protocole non fiable et ne garantit pas la livraison ou l'ordre des paquets.

2. Taille de message : Les messages DNS sur UDP sont limités en taille (typiquement 512 octets sans EDNS(0), ou jusqu'à 4096 octets avec EDNS(0)), ce qui le rend impraticable pour la plupart des transferts de zone.

3. Absence de standardisation : Il n'y a pas de format ou de comportement standardisé pour AXFR sur UDP dans les spécifications DNS modernes.

Pour ces raisons, AXFR sur UDP est considéré comme obsolète et NE DOIT PAS être implémenté dans les nouveaux logiciels DNS. Toute référence à AXFR sur UDP dans les documents DNS plus anciens est historique et devrait être ignorée.

Recommandation : Les clients et serveurs AXFR DOIVENT utiliser TCP. Si une synchronisation de zone basée sur UDP est nécessaire pour une raison quelconque, les implémenteurs devraient envisager d'utiliser IXFR [RFC1995] sur UDP, bien que même IXFR soit typiquement réalisé sur TCP.