Transfert de zone DNS - Définition

Introduction

Le transfert de zone DNS également connu de son opcode mnémotechnique AXFR, est un type de transaction DNS. C'est l'un des nombreux mécanisme disponible pour répliquer les bases de données distribuées contenant les données DNS au travers d'un ensemble de serveurs DNS. Le transfert de zone peut être effectué de deux manières différentes : le transfert de zone complet (AXFR) ou le transfert de zone incrémental (IXFR). Quasi universel à un moment, il périclite au profit d'autres mécanismes de réplication de bases de données fournis par les systèmes DNS modernes.

Fonctionnement

Fonctionnement AXFR (transfert complet)

Le transfert de zone fonctionne sur une transaction en mode Client serveur au dessus de TCP. Il y a le client (l'esclave ou slave) qui requiert les informations d'une partie de la base de donnée distribuée (zone) auprès d'un serveur (le maître ou master) qui les fournit (RFC 2136). Il y a toujours un serveur primaire maître par zone. Ces définitions sont complémentaires avec celles de la RFC 1035 (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 presque exclusivement dédiés au processus du 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 plus petit) à 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é 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 (protocole UDP). 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.

Fonctionnement IXFR (transfert incrémental)

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 renvoi au maître l'entrée SOA de la copie de la zone qu'il détiens,
• le serveur maître peut alors répondre suivant le protocole AXFR et transfert 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 comprennes deux listes, une pour les enregistrements à supprimer, puis l'autre pour ceux à insérer.

Fonctionnement NOTIFY

Un transfert de zone est entièrement à l'initiative de l'esclave. Celui-ci les planifie les transfert 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, certain serveurs maître 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.

Sécurité

L'utilisation de TSIG (RFC 2845) 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.