1. Introduction

Le système de noms de domaine dispose de mécanismes standard pour maintenir des serveurs cohérents pour une zone, composés de trois éléments. Le transfert autoritaire (AXFR) est défini dans "Domain Names - Concepts and Facilities" [RFC1034] (appelé RFC 1034 dans ce document) et "Domain Names - Implementation and Specification" [RFC1035] (ci-après RFC 1035). Le transfert de zone incrémentiel (IXFR) est défini dans "Incremental Zone Transfer in DNS" [RFC1995]. Un mécanisme de notification rapide des changements de zone (NOTIFY) est défini dans "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. L'objectif de ces mécanismes est de permettre à un ensemble de serveurs de noms DNS de rester autoritaires de manière cohérente pour une zone donnée.

Ce document re-spécifie le mécanisme AXFR tel qu'il est déployé sur l'Internet en général, avec la précision attendue des normes Internet modernes, et met ainsi à jour RFC 1034 et RFC 1035.

1.1. Définition des termes

Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans "Key words for use in RFCs to Indicate Requirement Levels" [BCP14].

L'utilisation de "newer"/"new" et "older"/"old" DNS fait référence aux implémentations écrites respectivement après et avant la publication de ce document.

"Implémentation DNS à usage général" fait référence aux logiciels DNS développés pour une utilisation généralisée. Cela inclut les résolveurs et serveurs librement accessibles sous forme de bibliothèques et de processus autonomes. Cela inclut également les implémentations propriétaires utilisées uniquement pour prendre en charge les offres de services DNS.

"Implémentation DNS clé en main" fait référence aux implémentations DNS personnalisées à usage unique. Ces implémentations consistent en des logiciels qui emploient le format de message du protocole DNS mais ne se conforment pas à l'ensemble des fonctionnalités DNS.

Les termes "session AXFR", "serveur AXFR" et "client AXFR" seront introduits dans le premier paragraphe de la Section 2, après avoir établi plus de contexte.

1.2. Portée

En termes généraux, les serveurs de noms autoritaires pour une zone donnée peuvent utiliser divers moyens pour assurer la cohérence du contenu de zone qu'ils servent. Par exemple, certaines implémentations DNS assemblent des réponses à partir de données stockées dans des bases de données relationnelles (par opposition aux fichiers maîtres), en s'appuyant sur les moyens non-DNS de la base de données pour synchroniser les instances de base de données. Certaines de ces solutions non-DNS interopèrent d'une manière ou d'une autre. Cependant, AXFR, IXFR et NOTIFY sont les seuls mécanismes intrabande définis par protocole pour fournir la cohérence d'un ensemble de serveurs de noms, et ce sont les seuls mécanismes spécifiés par l'IETF.

Ce document ne couvre pas les situations DNS incohérentes. Il existe des applications du DNS dans lesquelles les serveurs d'une zone ne sont pas destinés à être cohérents.

1.3. Contexte

Un client AXFR émet une requête pour recevoir le contenu d'une zone depuis un serveur AXFR. Ces transferts sont un type de requête DNS et sont conformes aux spécifications du protocole DNS, y compris les messages d'en-tête de requête et de réponse.

Le contenu de zone correspond aux RR DNS autoritaires appartenant aux noms de domaine au sein de la zone. Typiquement, tous les RR autoritaires d'une zone sont transférés par une session AXFR, avec une exception. Lors du suivi d'une coupure de zone, les enregistrements de colle ne sont pas transférés.

Un transfert de zone est initié par le minuteur de rafraîchissement SOA DNS, un message NOTIFY ou une intervention de l'opérateur (bien que d'autres moyens ne soient pas exclus). Un AXFR est souvent limité aux serveurs spécifiquement configurés comme secondaires des serveurs primaires pour la zone, et les requêtes d'autres clients sont refusées.

La définition originale de 1035 d'AXFR spécifiait son exécution sur TCP. Cette spécification ne prend en charge qu'AXFR sur TCP. Pour être complet, cependant, cette spécification mentionne AXFR-sur-UDP dans une annexe informative.

Une session AXFR consiste en un message de requête AXFR, un ou plusieurs messages de réponse AXFR, et enfin, la terminaison de la connexion TCP. Une session AXFR est dite "réussie" si les deux conditions suivantes sont remplies : (1) le client AXFR a reçu une séquence de réponse AXFR réussie, et (2) le client AXFR a fermé la connexion TCP ou le client a reçu confirmation que le serveur AXFR a fermé la connexion TCP.

Ce document n'aborde pas la sécurité du transfert de zone. Les considérations de sécurité pertinentes sont discutées dans la Section 8.

1.4. Couverture et relation avec la spécification AXFR originale

Ce document couvre une session AXFR autoritaire, non consciente de DNS UPDATE, de primaire à secondaire sans sécurité employée, et la zone transférée est une zone DNS "normale", pour le transport IPv4. C'est-à-dire que le serveur est un maître ou primaire pour la zone et le client est un serveur secondaire ou esclave. La définition a été rédigée de manière à permettre un mécanisme d'extension pour indiquer la couverture de valeurs de paramètres supplémentaires.

Pour référence, ce document note ce qui suit (mais ne définit aucune de ces variantes) :

• Les transferts de zone peuvent être effectués entre un esclave et un autre esclave (tous sont des serveurs autoritaires).

• Un client de transfert de zone peut être un résolveur ou un validateur de zone collectant des données (applications non autoritaires).

• Il existe une extension de protocole optionnelle qui permet des "transferts incrémentiels" -- Transfert de zone incrémentiel (IXFR) [RFC1995].

• DNSSEC (via RFC 4033 [RFC4033], RFC 4034 [RFC4034] et RFC 4035 [RFC4035]) définit un protocole de sécurité pour DNS.

• DNS UPDATE (RFC 2136 [RFC2136]) fournit un moyen par lequel une zone peut être mise à jour dynamiquement.

• Le transport IPv6 peut être utilisé.

L'objectif en mentionnant ceux-ci est de clarifier que bien que les mécanismes décrits dans ce document ne s'appliquent qu'à un scénario spécifique, il existe des scénarios connexes qui se réfèrent à ce document pour fournir un contexte. Les variantes listées ne sont pas toutes équivalentes, ne sont certainement pas indépendantes les unes des autres, et peuvent ou non être dans la portée de ce document.

Ce document a intentionnellement une portée étroite, mais est ainsi rédigé pour indiquer qu'il décrit un mécanisme extensible.