3. Contenu de la zone

Cette section décrit quels enregistrements de ressources DNS (RR) sont inclus dans une réponse AXFR et lesquels sont exclus. Le contenu d'un transfert de zone n'est pas arbitraire; des règles spécifiques régissent ce qui est et n'est pas inclus.

3.1. Enregistrements à inclure

Un serveur AXFR DOIT inclure les RR suivants dans une réponse AXFR :

1. RR SOA : Le RR SOA pour l'apex de la zone DOIT apparaître comme le premier RR dans la section de réponse du premier message de réponse et comme le dernier RR dans la section de réponse du dernier message de réponse.

2. Tous les RR autoritaires : Tous les RR autoritaires appartenant aux noms de domaine au sein de la zone DOIVENT être inclus. Cela inclut, sans s'y limiter, les types de RR suivants :

   • RR NS à l'apex de la zone
   • A, AAAA, MX, CNAME, TXT et autres types de RR standard
   • RR liés à DNSSEC (DNSKEY, RRSIG, NSEC, NSEC3, DS à l'apex de la zone si présent)
   • Tout type de RR inconnu ou expérimental défini selon [RFC3597]

3. RRsets : Tous les RR du même nom de propriétaire, classe et type constituent un RRset. Tous les membres d'un RRset DOIVENT être inclus dans le transfert de zone. Il est RECOMMANDÉ que tous les RR du même RRset apparaissent consécutivement dans la réponse AXFR pour l'efficacité.

4. Non-terminaux vides : Les noms de domaine non-terminaux vides (ENT) ne possèdent aucun RR mais servent d'espaces réservés dans l'arbre des noms de domaine. Cependant, parce que les ENT ne possèdent pas de RR, ils ne sont pas explicitement représentés dans les réponses AXFR. Ils sont implicitement définis par l'existence de noms subordonnés.

Un serveur AXFR NE DOIT PAS inclure ce qui suit dans une réponse AXFR :

1. Données hors zone : Les RR qui n'appartiennent pas aux noms de domaine au sein de la zone NE DOIVENT PAS être inclus (sauf pour les enregistrements de colle, comme décrit dans la Section 3.3).

2. Données non autoritaires : Les données en cache, les indices ou toute autre information non autoritaire NE DOIVENT PAS être inclus.

3. RR OPT dans la section de réponse : Les pseudo-RR OPT EDNS(0) ne sont pas des données de zone et NE DOIVENT PAS apparaître dans la section de réponse. Ils PEUVENT apparaître uniquement dans la section additionnelle.

3.2. Enregistrements de délégation

Une coupure de zone (point de délégation) est un nom de domaine dans une zone où l'autorité est déléguée à une autre zone. À une coupure de zone, les RR NS indiquent la délégation. Le traitement des enregistrements de délégation dans AXFR est nuancé.

RR NS de délégation : Les RR NS à une coupure de zone (déléguant l'autorité à une zone enfant) DOIVENT être inclus dans la réponse AXFR. Ces RR NS sont autoritaires pour la zone parent et indiquent où l'autorité a été déléguée.

Exemple : Si la zone example.com contient une délégation à child.example.com, les RR NS pour child.example.com DOIVENT être inclus dans la réponse AXFR pour example.com.

RR DS aux coupures de zone : Pour les zones signées DNSSEC, les RR DS (Delegation Signer) PEUVENT apparaître à une coupure de zone dans la zone parent. Les RR DS à un point de délégation DOIVENT être inclus dans la réponse AXFR pour la zone parent.

Autres types de RR aux coupures de zone : À une coupure de zone, seuls les RR NS (et éventuellement les RR DS pour DNSSEC) sont autoritaires dans la zone parent. Les autres types de RR qui pourraient exister au même nom de domaine sont soit :

• Des enregistrements de colle (voir Section 3.3), ou
• Occultés par la coupure de zone (voir Section 3.5).

Aucun autre type de RR autoritaire (en dehors de NS et DS) n'existe à une coupure de zone dans la zone parent.

3.3. Enregistrements de colle

Les enregistrements de colle sont des enregistrements d'adresse (A ou AAAA) qui existent en dehors de la portée autoritaire de la zone mais sont nécessaires pour éviter les dépendances circulaires lors de la résolution des serveurs de noms de la zone.

Définition : Les enregistrements de colle sont des RR A ou AAAA qui fournissent des adresses IP pour les serveurs de noms listés dans les RR NS de la zone, où ces serveurs de noms résident dans une zone enfant déléguée.

Exemple : Si example.com délègue à child.example.com et que l'un des RR NS pour child.example.com est ns1.child.example.com, alors un RR A ou AAAA pour ns1.child.example.com serait de la colle dans le contexte de la zone example.com.

Comportement AXFR :

1. Les enregistrements de colle NE DOIVENT PAS être inclus dans une réponse AXFR. Les enregistrements de colle sont des données hors zone et ne sont pas autoritaires pour la zone transférée. Le serveur AXFR NE DOIT PAS envoyer d'enregistrements de colle dans la section de réponse d'une réponse AXFR.

2. Le client AXFR est responsable de l'obtention des enregistrements de colle par d'autres moyens (par exemple, en interrogeant la zone enfant ou en s'appuyant sur des données en cache).

Justification : L'inclusion d'enregistrements de colle dans les réponses AXFR mélangerait des données autoritaires et non autoritaires, conduisant potentiellement à de la confusion et de l'incohérence. En excluant les enregistrements de colle, la réponse AXFR contient uniquement des données autoritaires pour la zone.

Note historique : Certaines anciennes implémentations DNS incluaient des enregistrements de colle dans les réponses AXFR. Les implémentations modernes NE DOIVENT PAS inclure d'enregistrements de colle, car ce comportement est non standard et peut causer des problèmes d'interopérabilité.

3.4. Compression de nom

Le format de message DNS prend en charge la compression de nom, une technique pour réduire la taille des messages DNS en remplaçant les noms de domaine répétés par des pointeurs vers des occurrences antérieures du même nom dans le message.

AXFR et compression de nom :

1. La compression de nom PEUT être utilisée dans les messages de réponse AXFR individuels. Chaque message DNS dans une séquence AXFR est indépendant en termes de compression de nom; les pointeurs NE DOIVENT PAS référencer des noms dans des messages précédents ou suivants.

2. La compression de nom est particulièrement bénéfique dans les réponses AXFR car de nombreux RR partagent des suffixes de nom de domaine communs (par exemple, le nom de zone lui-même).

3. Un serveur AXFR DEVRAIT utiliser la compression de nom pour réduire la bande passante et améliorer l'efficacité, mais ce n'est pas obligatoire.

4. Un client AXFR DOIT prendre en charge la compression de nom et décompresser correctement les noms dans les réponses AXFR.

3.5. Noms occultés

Un nom occulté est un nom de domaine qui serait normalement dans une zone mais est caché de la vue de la zone en raison d'une coupure de zone. Les noms occultés existent subordonnés à un point de délégation.

Exemple : Si example.com délègue à child.example.com, tous les noms de domaine subordonnés à child.example.com (tels que www.child.example.com ou ftp.child.example.com) sont occultés du point de vue de la zone example.com.

Comportement AXFR :

1. Les noms occultés et leurs RR associés NE DOIVENT PAS être inclus dans une réponse AXFR pour la zone parent. Seule la coupure de zone (les RR NS au point de délégation) est incluse.

2. Le contenu de la zone déléguée (child.example.com dans l'exemple) est transféré uniquement via une session AXFR spécifiquement pour cette zone.

Justification : L'inclusion de noms occultés dans la réponse AXFR d'une zone parent violerait la structure hiérarchique du DNS et mélangerait des données de plusieurs zones.

Cas spécial - DNAME : Si une zone contient un RR DNAME [RFC2672], le DNAME crée une redirection, et tous les noms subordonnés au propriétaire du DNAME sont effectivement occultés de la même manière que les noms subordonnés à une délégation. Les noms occultés par DNAME NE DOIVENT PAS être inclus dans une réponse AXFR.