Transfert de zone DNS





Si ce bandeau n'est plus pertinent, retirez-le. Cliquez pour voir d'autres modèles.



Le fond de cet article sur l'informatique est à vérifier (septembre 2016).

Améliorez-le ou discutez des points à vérifier.
Si vous venez d’apposer le bandeau, merci d’indiquer ici les points à vérifier.




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écanismes disponibles 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). Il entre en concurrence avec les mécanismes de réplication de bases de données fournis par les systèmes DNS modernes.




Sommaire






  • 1 Fonctionnement


    • 1.1 Fonctionnement AXFR (transfert complet)


    • 1.2 Fonctionnement IXFR (transfert incrémental)


    • 1.3 Fonctionnement NOTIFY


    • 1.4 Sécurité




  • 2 Problèmes opérationnels


    • 2.1 Modification du numéro de série


    • 2.2 Comparaison des numéros de série


    • 2.3 Ressources enregistrées (RR) multiples




  • 3 Notes et références


  • 4 Voir aussi


    • 4.1 Requests For Comments (RFC)







Fonctionnement |



Fonctionnement AXFR (transfert complet) |


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



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



Fonctionnement NOTIFY |


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.



Sécurité |


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.



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



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 (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 déclenchent pas le transfert de zone sur les mêmes critères.



Ressources enregistrées (RR) multiples |


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



Notes et références |





  1. ↑ (en) Request for Comments no 2136.


  2. ↑ (en) Request for Comments no 1035.


  3. ↑ (en) Request for Comments no 2845.


  4. ↑ (en) Request for Comments no 1982.


  5. ↑ (en) Request for Comments no 1034.




Voir aussi |



  • principaux enregistrements DNS (RR).


Requests For Comments (RFC) |




  • 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 de l’informatique
  • Portail d’Internet Portail d’Internet



  1. ↑ (en) Request for Comments no 1034.


  2. ↑ (en) Request for Comments no 1995.


  3. ↑ (en) Request for Comments no 1996.








-

Popular posts from this blog

Ellipse (mathématiques)

Image
Pour les articles homonymes, voir Ellipse. L'ellipse est le lieu des points dont la somme des distances à deux points fixes, dits foyers, est constante. Section du cône ou projection du cercle. En géométrie, une ellipse est une courbe plane fermée obtenue par l’intersection d’un cône de révolution avec un plan, à condition que celui-ci coupe l'axe de rotation du cône ou du cylindre : c'est une conique d'excentricité strictement comprise entre 0 et 1. On peut également la définir comme le lieu des points dont la somme des distances à deux points fixes, dits foyers, est constante (sa construction par la méthode du jardinier est très simple). Dans la vie courante, l’ellipse est la forme qu'on perçoit en regardant un cercle en perspective, ou la figure formée par l’ombre d'un disque sur une surface plane. On retrouve aussi, en première approximation [ 1 ] , des ellipses dans les trajectoires des corps célestes (planètes, comètes ou satellites arti...
Read more

Quarter-circle Tiles

Image
up vote 0 down vote favorite I have $99$ identical square tiles, each with a quarter-circle drawn on it like this: [asy] size(1.5cm); draw(Arc((2,0),1,90,180),red+1); draw((0,0)--(2,0)--(2,2)--(0,2)--(0,0)); [/asy] When I arrange the tiles in a $9times 11$ rectangular grid, each with a random orientation, what is the expected value of the number of full circles I form? I think this problem has to do with finding the chance any given 2x2 square has a circle, but I can't find it. expected-value share | cite | improve this question asked Nov 20 at 15:03 6minecraftninja 1 2 ...
Read more

Mont Emei

Image
Mont Emei.mw-parser-output .entete.map{background-image:url("//upload.wikimedia.org/wikipedia/commons/7/7a/Picto_infobox_map.png")} Vue du sommet Wanfo du mont Emei Géographie Altitude 3 099  m , Wanfo Coordonnées 29° 31′ 11″ nord, 103° 19′ 57″ est Administration Pays   Chine Province Sichuan Ville-préfecture Leshan Géolocalisation sur la carte : Sichuan Mont Emei Géolocalisation sur la carte : Chine Mont Emei modifier   Paysage panoramique du mont Emei, incluant le paysage panoramique du grand Bouddha de Leshan *   Patrimoine mondial de l'UNESCO Passerelle en bois sur le versant ouest Pays   Chine Subdivision Sichuan Type Mixte Critères (iv) (vi) (x) Superficie 15 400 ha Numéro d’identification 779 Zone géographique Asie et Pacifique  ** Année d’inscription 1996 (20 e session) * Descriptif officiel UNESCO ** Classification géog...
Read more