2. Messages AXFR

Une session AXFR consiste en une seule connexion TCP et est initiée par un message de requête DNS. Ce message de requête détermine la zone à transférer et certaines caractéristiques de la session. Après la requête vient le transfert du contenu de la zone, en supposant une requête réussie, puis une terminaison de connexion.

Les définitions suivantes sont utilisées dans ce document. Le "client AXFR" est l'hôte qui initie la connexion TCP et envoie la requête DNS AXFR. Le "serveur AXFR" est l'hôte qui reçoit la requête AXFR et envoie la ou les réponses AXFR. Une "session AXFR" consiste en une requête AXFR et la séquence de réponses AXFR correspondant à cette requête.

Un AXFR est l'un des plusieurs types de requête (QTYPE) définis pour le DNS; cependant, contrairement à la plupart des types de requête, AXFR peut nécessiter plusieurs messages DNS pour répondre complètement à une requête. Le format de la requête initiale et des messages de réponse sont des messages DNS standard, définis dans RFC 1035 et les documents ultérieurs. Certains champs du message DNS sont davantage restreints lorsque le type de requête est un AXFR.

Tout au long de ce document, les requêtes et réponses AXFR seront divisées en sections suivant la structure du message DNS. Les cinq sections sont : (1) En-tête, (2) Question, (3) Réponse, (4) Autorité, et (5) Additionnelle.

Cette section documente les messages de requête et de réponse, y compris les restrictions sur les requêtes et les exigences sur les serveurs. Cela aborde également l'utilisation de la connexion TCP.

2.1. Requête AXFR

Cette sous-section décrit le format et la sémantique du message de requête qui initie une session AXFR. Le terme "DNS normal" sera utilisé pour décrire le comportement régi par la spécification DNS standard (RFC 1034, RFC 1035 et mises à jour).

Une requête AXFR est comme un message de requête DNS normal avec QTYPE AXFR; cependant, des restrictions supplémentaires sont imposées sur une "requête AXFR bien formée". Un client AXFR envoyant une requête AXFR DEVRAIT se conformer aux règles d'une requête bien formée. Un serveur AXFR DOIT répondre à une requête AXFR qui ne se conforme pas à ces règles de la même manière qu'il répondrait à toute requête incorrectement formatée. (Il s'agit généralement d'une réponse FORMERR.)

Une requête AXFR bien formée a les caractéristiques suivantes :

1. L'OPCODE de l'en-tête DNS DOIT être zéro (une requête standard).

2. Le compte de section de question de l'en-tête DNS (QDCOUNT) DOIT être 1.

3. Le compte de section de réponse de l'en-tête DNS (ANCOUNT), le compte de section d'autorité (NSCOUNT), et le compte de section additionnelle (ARCOUNT) DOIVENT tous être 0.

4. La section de question DOIT contenir une seule question avec :

   • QTYPE égal à AXFR [RFC5395] (252 décimal);
   • QCLASS égal à la classe de zone ou ANY;
   • QNAME égal au nom de la zone à transférer.

5. Les réponses AXFR PEUVENT être d'une version de protocole DNS supérieure à celle de la requête.

2.1.1. Valeurs d'en-tête

QR : DOIT être 0 (Requête)

OPCODE : DOIT être 0 (Requête standard)

AA : Non examiné (non pertinent pour une requête)

TC : DOIT être 0 (Non tronqué) - Une requête AXFR avec TC défini à 1 est incorrectement formatée.

RD : PEUT être 0 ou 1 - Le bit Recursion Desired est ignoré par le serveur AXFR; il n'affecte ni le comportement d'une requête AXFR ni ne joue un rôle dans les transferts autoritaires. Le paramétrage du bit RD dans un message de requête AXFR n'est pas un indicateur fiable que la requête est une requête récursive.

RA : Non examiné (utilisé uniquement dans les réponses)

Z : DOIT être 0 (réservé pour usage futur) - Selon l'exigence de la spécification DNS, les bits réservés DOIVENT être zéro dans une requête et DOIVENT être ignorés dans une réponse. Par conséquent, un client AXFR DOIT définir les bits Z à zéro, et un serveur AXFR DOIT ignorer leur valeur. Une requête AXFR avec l'un des bits réservés (Z) défini à une valeur non nulle est incorrectement formatée.

AD : DOIT être 0 - Le bit Authentic Data n'est défini que pour les réponses [RFC4035].

CD : PEUT être 0 ou 1 - Le bit Checking Disabled n'est pertinent que pour les réponses, il n'a donc pas de signification définie pour une requête de transfert de zone. Un client AXFR PEUT définir ce bit; un serveur AXFR DOIT ignorer sa valeur.

RCODE : DOIT être 0 (Pas d'erreur) - Le champ de code de réponse n'est défini que pour les réponses.

QDCOUNT : DOIT être 1

ANCOUNT : DOIT être 0

NSCOUNT : DOIT être 0

ARCOUNT : DOIT être 0 ou PEUT être supérieur à zéro si la requête inclut des options EDNS(0) [RFC2671], TSIG [RFC2845], ou SIG(0) [RFC2931].

Pour les considérations EDNS(0), TSIG et SIG(0), voir la Section 2.2.5.

2.1.2. Section de question

La section de question DOIT se conformer à celle spécifiée dans RFC 1035, contenant une seule question avec les caractéristiques suivantes :

QNAME : Le nom de la zone à transférer, qui DOIT être un nom de domaine DNS valide.

QTYPE : La valeur est 252 (pour AXFR) selon [RFC5395].

QCLASS : La classe de la zone à transférer. Parce que les requêtes AXFR peuvent représenter un risque de sécurité majeur, un serveur AXFR limitera probablement l'accès au transfert de zone par le biais d'une politique (via des listes de contrôle d'accès, l'authentification TSIG, etc.), et un transfert de zone ne devrait pas être servi à n'importe quel demandeur. La valeur QCLASS spéciale * (ANY, 255 décimal) PEUT être utilisée à des fins de rétrocompatibilité. Lorsque QCLASS est ANY, un serveur AXFR ne doit pas retourner les données de zone pour toutes les classes de données disponibles, mais peut choisir une classe et transférer cette zone ou peut refuser la requête. (Cette dernière option est RECOMMANDÉE pour une implémentation DNS à usage général.) Les clients AXFR soigneusement écrits demandent des transferts de zone via des classes spécifiques.

2.1.3. Section de réponse

La section de réponse DOIT être vide (ANCOUNT doit être 0) dans une requête AXFR.

2.1.4. Section d'autorité

La section d'autorité DOIT être vide (NSCOUNT doit être 0) dans une requête AXFR.

2.1.5. Section additionnelle

La section additionnelle d'un message de requête AXFR peut contenir des enregistrements de ressources (RR) EDNS(0) [RFC2671] pour indiquer le support et les paramètres EDNS. Elle peut également contenir des RR TSIG [RFC2845] ou SIG(0) [RFC2931] à des fins d'authentification. La présence d'options TSIG ou SIG(0) permet l'authentification de la requête AXFR, permettant potentiellement des politiques d'autorisation plus permissives sur le serveur AXFR.

Lorsque EDNS(0) est utilisé, le pseudo-RR OPT est placé dans la section additionnelle, et ARCOUNT est incrémenté en conséquence. Le numéro de version annoncé par EDNS(0) indique une volonté d'accepter des paquets formatés pour cette version. Un client AXFR qui n'est pas conscient d'EDNS définira ARCOUNT à 0 et n'inclura pas de RR OPT. Un serveur AXFR qui n'est pas conscient d'EDNS ignorera le RR OPT et peut choisir de traiter la requête comme mal formée si ARCOUNT est supérieur à 0 et que le traitement supplémentaire (examen de ces RR supplémentaires) est activé.

Une requête AXFR avec un SIG(0) aura ARCOUNT égal à 1 plus le nombre de RR OPT dans la section additionnelle. Un RR TSIG n'est pas compté dans ARCOUNT, car TSIG est une technique d'authentification de message alternative dans DNS. Voir [RFC2845] pour les considérations TSIG.

TSIG et EDNS(0) PEUVENT être utilisés simultanément.

2.2. Réponse AXFR

Cette sous-section décrit le format et la sémantique des réponses aux requêtes AXFR. Les réponses sont envoyées après qu'une connexion TCP est établie et qu'une requête AXFR est analysée.

Un serveur AXFR DOIT être capable de gérer une requête avec des drapeaux ou des attributs inattendus, non définis ou non pris en charge en répondant avec une réponse d'erreur DNS standard. Les conditions qui causent diverses erreurs sont élaborées dans les sous-sections suivantes.

Il existe quatre catégories de réponses du serveur AXFR à une requête AXFR :

1. Une réponse mal formée : Cela résulte si la requête AXFR reçue via TCP n'est pas un message de requête DNS légal ou si le message DNS ne se conforme pas aux exigences d'une requête AXFR bien formée telle que spécifiée dans la Section 2.1. La réponse à une requête mal formée DEVRAIT être un seul message de réponse DNS avec un RCODE approprié (FORMERR, NOTIMP, REFUSED, etc.).

2. Une réponse refusée : Si un message DNS reçu est une requête AXFR légale, mais que des considérations de politique dictent que ce client AXFR particulier n'est pas autorisé à effectuer des transferts de zone (pour la zone en question ou en général), la réponse DEVRAIT être un seul message de réponse DNS avec RCODE REFUSED.

3. Une réponse vide : Si la zone transférée est vide (toutes les données autoritaires à l'apex de zone sont en dehors de la zone), le serveur AXFR DEVRAIT retourner un seul message de réponse avec seulement un RR SOA dans la section de réponse. Ce RR SOA sera le seul RR dans la zone. Les conditions pour une zone vide sont très inhabituelles et résultent d'opérations hors bande (éditions de zone, mises à jour dynamiques ou autres moyens) qui ont supprimé tout sauf le SOA obligatoire de la zone.

4. Une réponse réussie : En supposant qu'il n'y ait pas de problèmes de politique ou de malformation, le serveur AXFR répond avec un ou plusieurs messages de réponse DNS qui contiennent collectivement toutes les données autoritaires de la zone transférée, sous réserve de certaines inclusions et exclusions spécifiques décrites dans la Section 3.

Les trois premiers types de réponse sont livrés via un seul message DNS. Le dernier type, la réponse réussie, peut consister en un ou plusieurs messages de réponse DNS envoyés séquentiellement sur la connexion TCP.

Un serveur AXFR qui implémente EDNS(0), TSIG ou SIG(0) DOIT être préparé à recevoir des messages de requête AXFR qui ne contiennent pas les options correspondantes. Inversement, un serveur AXFR PEUT choisir d'ignorer la présence d'options EDNS(0), TSIG ou SIG(0) dans le message de requête (par exemple, s'il ne les prend pas en charge ou ne les exige pas). Cependant, si un serveur AXFR implémente EDNS(0), TSIG ou SIG(0) et choisit d'utiliser des informations de ces options dans la requête, il DOIT inclure les informations d'option appropriées dans ses messages de réponse AXFR.

Un client AXFR DOIT être préparé à recevoir des réponses AXFR dans lesquelles le bit TC (troncature) n'est pas utilisé ou significatif. Parce qu'AXFR opère sur TCP et est autorisé à utiliser plusieurs messages DNS dans une séquence de réponse, la troncature n'est pas nécessaire. (L'utilisation du bit TC est explicitement couverte dans la Section 2.2.1.)

2.2.1. Valeurs d'en-tête

QR : DOIT être 1 (Réponse)

OPCODE : DOIT être 0 (Requête standard)

AA : Le bit AA (Réponse autoritaire) DEVRAIT être défini à 1 dans tous les messages de réponse. Bien que le serveur AXFR soit probablement autoritaire pour la zone transférée, il n'y a pas d'exigence stricte que ce soit le cas.

TC : DOIT être 0 (Non tronqué) - Parce qu'AXFR opère sur TCP et peut utiliser plusieurs messages de réponse, il n'est pas nécessaire de définir le bit TC.

RD : Le bit RD dans la réponse copie le bit RD de la requête (selon la spécification DNS). Le bit RD n'a pas de signification pour AXFR; sa valeur n'affecte pas le comportement AXFR.

RA : Le bit RA (Récursion disponible) PEUT être défini ou effacé dans la réponse selon les politiques générales du serveur AXFR. Dans le cas d'un transfert de zone, la récursion n'est pas applicable, donc la valeur de RA n'est pas significative dans ce contexte.

Z : DOIT être 0 (Réservé) - Les bits réservés DOIVENT être définis à zéro par un serveur AXFR et DOIVENT être ignorés par un client AXFR.

AD : PEUT être 0 ou 1 - Pour les serveurs AXFR conscients de DNSSEC servant des zones signées DNSSEC, le bit AD (Données authentiques) PEUT être défini dans les réponses AXFR selon les exigences DNSSEC [RFC4035]. Pour les zones qui ne sont pas signées DNSSEC, le bit AD DEVRAIT être 0. Un client AXFR qui n'est pas conscient de DNSSEC ignore le bit AD.

CD : DEVRAIT être 0 - Le bit CD (Vérification désactivée) n'est pertinent que pour les résolveurs, pas pour les serveurs autoritaires. Pour les réponses AXFR, le bit CD DEVRAIT être 0 et n'a pas de signification définie.

RCODE : Le code de réponse indique le résultat de la requête AXFR. Les valeurs courantes incluent :

• NOERROR (0) : Transfert réussi (tous les messages de réponse dans une séquence de réponse AXFR réussie ont RCODE défini à NOERROR).
• FORMERR (1) : Erreur de format dans la requête.
• SERVFAIL (2) : Défaillance du serveur lors du traitement de la requête.
• NOTIMP (4) : Type de requête non implémenté.
• REFUSED (5) : Transfert de zone refusé par politique.
• NOTAUTH (9) : Le serveur n'est pas autoritaire pour la zone demandée (défini dans [RFC2136]).

Pour une réponse AXFR réussie, tous les messages de réponse DNS dans la session AXFR DOIVENT avoir RCODE défini à NOERROR. Si un message de réponse DNS dans une session AXFR a RCODE défini à autre chose que NOERROR, le client AXFR DOIT considérer le transfert de zone comme ayant échoué.

QDCOUNT : DOIT être 1 - La section de question est répétée dans chaque message de réponse, copiant la question de la requête.

ANCOUNT : Indique le nombre de RR dans la section de réponse. La valeur varie en fonction du nombre de RR qui rentrent dans chaque message de réponse.

NSCOUNT : DOIT être 0 - Aucune section d'autorité n'est incluse dans les messages de réponse AXFR.

ARCOUNT : DOIT être 0 ou supérieur si EDNS(0), TSIG ou SIG(0) est utilisé. Typiquement, ARCOUNT est 0 pour les réponses AXFR.

2.2.2. Section de question

La section de question dans la réponse DOIT être identique à la section de question dans la requête AXFR correspondante. Cela signifie que QDCOUNT DOIT être 1, et la seule question DOIT correspondre à la question de la requête.

2.2.3. Section de réponse

La section de réponse contient les données de zone transférées. Les exigences pour le contenu de la section de réponse sont :

1. RR SOA : Le premier RR dans le premier message de réponse d'une réponse AXFR DOIT être le RR SOA pour la zone. Le dernier RR dans le dernier message de réponse d'une réponse AXFR DOIT également être le RR SOA pour la zone (c'est-à-dire, le même RR SOA apparaît au début et à la fin du transfert).

2. RR intermédiaires : Entre les deux RR SOA (le premier et le dernier), la section de réponse du ou des messages de réponse contient tous les autres RR autoritaires pour la zone (sous réserve des restrictions de la Section 3).

3. Ordre : L'ordre des RR dans la section de réponse (autres que les premier et dernier RR SOA) n'est pas défini. Cependant, tous les RR du même RRset (même nom de propriétaire, classe et type) DEVRAIENT être regroupés ensemble pour l'efficacité.

4. Messages multiples : Si les données de zone ne rentrent pas dans un seul message de réponse DNS, le serveur AXFR envoie plusieurs messages de réponse. Chaque message de réponse après le premier continue avec des données de zone supplémentaires, et le dernier message se termine par le RR SOA final.

2.2.4. Section d'autorité

La section d'autorité DOIT être vide (NSCOUNT = 0) dans les messages de réponse AXFR. L'inclusion d'enregistrements NS ou d'autres données d'autorité dans la section d'autorité d'une réponse AXFR est explicitement interdite.

2.2.5. Section additionnelle

La section additionnelle des messages de réponse AXFR est généralement vide, mais elle PEUT contenir des RR EDNS(0), TSIG ou SIG(0) si ces options ont été négociées ou sont utilisées.

EDNS(0) : Si la requête AXFR contenait un RR OPT EDNS(0), le serveur AXFR PEUT inclure des RR OPT dans les sections additionnelles de ses messages de réponse. EDNS(0) dans les réponses AXFR est utilisé principalement pour signaler des capacités étendues et des tailles de tampon.

TSIG : Si TSIG est utilisé pour l'authentification, les RR TSIG sont inclus dans la section additionnelle des messages de réponse AXFR. La signature TSIG est appliquée différemment dans les réponses AXFR multi-messages :

• Le premier message de réponse dans une séquence AXFR réussie DOIT inclure un RR TSIG.
• Les messages intermédiaires PEUVENT omettre le RR TSIG (les intermédiaires non signés sont autorisés).
• Le dernier message de réponse DOIT inclure un RR TSIG.

Voir [RFC2845] pour les considérations TSIG détaillées.

SIG(0) : Si SIG(0) est utilisé, chaque message de réponse contenant un SIG(0) aura ARCOUNT incrémenté en conséquence.

2.3. Abandons de connexion TCP

Un client AXFR ou un serveur AXFR PEUT abandonner une session AXFR en cours en fermant la connexion TCP. Les raisons d'abandonner une connexion incluent :

• Messages DNS mal formés ou inattendus.
• Délais d'attente (délais de lecture ou d'écriture).
• Échecs d'autorisation (par exemple, échec de validation TSIG).
• Erreurs internes du serveur.
• Épuisement des ressources.

Une connexion abandonnée DOIT être interprétée par le client AXFR comme un transfert de zone échoué. Le client AXFR NE DEVRAIT PAS valider les données de zone partielles reçues avant la fermeture de la connexion.

Un serveur AXFR PEUT utiliser la fermeture de connexion TCP comme indication au client AXFR que le transfert de zone a échoué.