Transfert de zone DNS

Transfert de zone DNS

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[réf. nécessaire].

Sommaire

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, 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.

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.

Problèmes opérationnels

Modification du numéro de série

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 le journée.

Certain 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 (en)). 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). Certain systèmes DNS permettent de s'affranchir du transfert de zone en utilisant en sous main les mécanismes de réplication multi-maître 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.

Comparaison des numéros de série

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

Ressources enregistrées (RR) multiples

Dans le processus actuel de transfert de données, chaque groupe d'enregistrements (RR) pour un nom de domaine unique était transféré par le serveur au client dans un message DNS séparé ce qui n'optimise pas du tout l'utilisation de la bande passante. Certain systèmes DNS pallient a 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,
  • grouper l'ensemble des enregistrements relatifs à un nom de domaine dans une seule réponse DNS si le taille le permet.

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

Notes et Références

Voir aussi

Requests For Comments (RFC)


Wikimedia Foundation. 2010.

Contenu soumis à la licence CC-BY-SA. Source : Article Transfert de zone DNS de Wikipédia en français (auteurs)

Игры ⚽ Поможем решить контрольную работу

Regardez d'autres dictionnaires:

  • Domain Name System — Pour les articles homonymes, voir DNS. Domain Name System Fonction Traduction de nom de domaine en adresse IP …   Wikipédia en Français

  • Domain Name System Security Extensions — DNSSEC (« Domain Name System Security Extensions ») est un protocole standardisé par l IETF permettant de résoudre certains problèmes de sécurité liés au protocole DNS. Les spécifications sont publiées dans la RFC 4033 et les suivantes… …   Wikipédia en Français

  • DNSSEC — Domain Name System Security Extensions DNSSEC (« Domain Name System Security Extensions ») est un protocole standardisé par l IETF permettant de résoudre certains problèmes de sécurité liés au protocole DNS. Les spécifications sont… …   Wikipédia en Français

  • Anti-spam — L anti spam (anti spamming, antipollupostage ou antipourriel) est un ensemble de systèmes et moyens techniques et juridiques de lutte contre le spam (ou « pourriel », courriers électroniques publicitaires non sollicités). Sommaire 1 La… …   Wikipédia en Français

  • Internet —  Ne doit pas être confondu avec World Wide Web. Internautes par millier d habitants dans le monde en 2009 …   Wikipédia en Français

  • Gestion de l'Internet — Internet Proportion d internautes par habitants dans le monde en 2000 …   Wikipédia en Français

  • Gestion de l'internet — Internet Proportion d internautes par habitants dans le monde en 2000 …   Wikipédia en Français

  • Origine d'internet — Internet Proportion d internautes par habitants dans le monde en 2000 …   Wikipédia en Français

  • Réseau Internet — Internet Proportion d internautes par habitants dans le monde en 2000 …   Wikipédia en Français

  • Réseau mondial — Internet Proportion d internautes par habitants dans le monde en 2000 …   Wikipédia en Français

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”