Transfert de zone DNS

Le transfert de zone fonctionne sur une transaction en mode client serveur au-dessus de TCP. Le client (l'esclave ou slave) requiert les informations d'une partie de la base de données distribuée (zone) auprès d'un serveur (le maître ou master) qui les fournit (RFC 2136[1]). Il y a toujours un serveur primaire maître par zone. Ces définitions sont complémentaires avec celles de la RFC 1035[2] (primaire et secondaire).

Le transfert de zone débute par la vérification de l'enregistrement DNS SOA de la zone considérée dont quatre paramètres sont utilisés lors du processus de transfert de zone  :

• le numéro de série (ou serial number) détermine la version des données,
• la période de rafraichissement (ou refresh) qui détermine le temps en secondes au bout duquel le serveur esclave interroge de nouveau le maître,
• la période de tentatives de rafraichissement (ou retry) qui détermine le temps en secondes au bout duquel le serveur esclave interroge de nouveau le maître après l'échec d'un transfert de zone,
• le temps de péremption (ou expire) qui détermine le temps au bout duquel le serveur esclave doit considérer les données périmées en cas d'échecs successifs de transfert de zone (le serveur esclave ne résout plus les noms de domaine de la zone).

Durant cette vérification, si le numéro de série (la version) de la zone du maître est identique (ou inférieur) à celui de la dernière copie de la zone en possession de l'esclave, le transfert s'arrête car aucun changement n'a eu lieu. Si cette version est plus récente (numéro de série de la zone du maître plus grand que celui de la copie de zone de l'esclave), l'esclave effectue la demande de transfert de zone en tant que telle.

Le transfert de zone proprement dit débute par l'envoi d'une requête DNS (opcode 0) par le client avec un QTYPE (type de requête ou query type) correspondant à AXFR (valeur 252) sur une connexion TCP vers le serveur maître. Le serveur répond avec une série de messages de réponse contenant l'ensemble des ressources enregistrées (RRdata) de la zone. La première réponse comprend l'enregistrement SOA de la zone, les autres enregistrement suivent sans ordre prédéfini. La fin du transfert est spécifiée par un nouvel envoi de l'enregistrement SOA.

Certains clients de transfert de zone utilisent leur client de résolution standard pour effectuer une requête SOA avant un transfert de zone. Ces clients n'ouvrent pas de connexion TCP sur le serveur jusqu'à ce qu'un transfert de zone soit nécessaire. Quoi qu'il en soit, si TCP peut indifféremment être utilisé comme protocole pour procéder à une transaction DNS normale comme un transfert de zone, d'autres clients de transfert de zone peuvent effectuer la première requête SOA puis le transfert de zone dans une même connexion TCP. Ces clients ouvrent systématiquement une connexion TCP sur le serveur maître pour la requête SOA préliminaire au transfert de zone.

Le transfert de zone incrémental ne diffère du transfert de zone complet que sur les points suivants :

• l'esclave utilise le QTYPE IXFR (valeur 251) à la place du QTYPE AXFR et précise au serveur la version (le numéro de série) de la zone qu'il pense être le bon (celui qu'il vient de récupérer dans la requête SOA préalable),
• l'esclave renvoie au maître l'entrée SOA de la copie de la zone qu'il détient,
• le serveur maître peut alors répondre suivant le protocole AXFR et transfère la zone complète comme décrit précédemment ou suivant le protocole incrémental IXFR. Ce dernier comprend la liste des modifications des ressources enregistrées de la zone (RRdata) dans l'ordre des numéros de série (des versions) successifs entre le numéro de série de la dernière zone détenue par l'esclave et celle actuellement détenue par le maître. Les modifications comprennent deux listes, une pour les enregistrements à supprimer, puis l'autre pour ceux à insérer.

Un transfert de zone est entièrement à l'initiative de l'esclave. Celui-ci planifie les transferts de zone, d'abord lorsqu'il n'a aucun enregistrement pour la zone (zone vide), puis à intervalles réguliers suivant les valeurs refresh, retry et expire spécifiées dans l'enregistrement SOA de la zone.

Cependant, certains serveurs maîtres peuvent envoyer un message NOTIFY aux serveurs esclaves déclarés et provoquer un transfert de zone en dehors de périodes planifiées par l'esclave dès que le serveur maître détecte une modification du numéro de série de la zone après un redémarrage ou un rechargement.

L'utilisation de TSIG (RFC 2845[3]) permet d'authentifier l'échange maître - esclave et d'assurer l'intégrité des données récupérées par le serveur esclave. Ce mécanisme permet au responsable d'une zone de s'assurer que les données fournies par le serveur esclave proviennent bien du bon serveur maître et qu'elles n'ont pas été altérées par un tiers lors de l'échange.

L'implémentation DNS BIND permet l'utilisation de ce mécanisme.

La décision d'effectuer ou non le transfert de zone repose uniquement sur le numéro de série de l'enregistrement SOA de la zone. Si ces numéros de série sont configurés à la main par un administrateur, celui-ci doit bien prendre garde à mettre à jour le numéro de série à chaque modification et que celui-ci augmente toujours sous peine de ne pas les propager. Ce processus peut facilement générer des erreurs. Une bonne pratique (nullement obligatoire, et pas toujours suivie) consiste à noter le numéro de série sous la forme AAAAMMJJSS où AAAA est l'année, MM le mois, JJ le jour et SS un numéro incrémenté au fur et à mesure des modifications effectuées dans la journée.

Certains systèmes DNS génèrent automatiquement ce numéro de série en fonction de la date de dernière modification du fichier de zone (cas de djbdns). La responsabilité est reportée sur le système d'exploitation et sa synchronisation. Si le fichier est édité pour ajouter un commentaire par exemple, le numéro de série est automatiquement modifié alors qu'aucun changement n'est opéré.

Le paradigme du numéro de série (et du transfert de zone) est qu'il impose d'avoir un serveur maître unique qui assure seul la référence de la zone pour l'ensemble des serveurs esclaves (un serveur esclave peut être maître d'un autre esclave). Certains systèmes DNS permettent de s'affranchir du transfert de zone en utilisant en sous-main les mécanismes de réplication multi-maîtres de certaines bases de données SQL ou LDAP (openldap, Active Directory). Il faut cependant noter que de telles implémentations s'avèrent très gourmandes en bande passante et nécessitent une synchronisation temporelle précise.

La comparaison des numéros de série devrait se baser sur l'arithmétique des numéros de série (en) décrite dans la RFC 1982[4]. Mais la RFC 1034[5] n'y fait pas explicitement référence ce qui a pour conséquence que l'ensemble des esclaves ne déclenchent pas le transfert de zone sur les mêmes critères.

Dans le processus original de transfert de données, chaque groupe d'enregistrements (RR) pour un nom de domaine unique est transféré par le serveur au client dans un message DNS séparé ce qui est peu efficace en termes de la bande passante. Certains systèmes DNS pallient ce problème en compressant des données et en les insérant comme suit :

• utilisation des enregistrements additionnels (additional section processing) pour inclure les entrées glue en même temps que les requêtes de type SRV, MX ou NS,
• groupement de l'ensemble des enregistrements relatifs à un nom de domaine dans une seule réponse DNS si la taille le permet.

Ces systèmes deviennent alors incompatibles avec ceux qui respectent strictement la norme ou implémentent une option spécifique.

• RFC 1034[1] Domain Names - Concepts and Facilities. (définit AXFR)
• RFC 1995[2] Incremental Zone Transfer in DNS. (définit IXFR)
• RFC 1996[3] A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
• draft-ietf-dnsext-axfr-clarify DNS Zone Transfer Protocol (AXFR) internet draft

• Portail de l’informatique
• Portail d’Internet