Exporter et documenter une zone DNS : conserver l’original et noter les lacunes

Définir ce que représente l’export

Consignez la zone, son périmètre public ou privé, le fournisseur, la représentation et la méthode de collecte autorisée avant d’organiser un export ultérieur. Quels jeux et paramètres la méthode documentée couvre-t-elle ? Un fichier téléchargeable, une empreinte identique ou une analyse syntaxique acceptée ne prouvent ni l’exhaustivité, ni l’équivalence fonctionnelle, ni une restauration réussie.

Conservez l’original dans un stockage protégé approuvé. S’il est obtenu ultérieurement avec autorisation, notez les date, heure et fuseau réels, la méthode, le nombre d’octets et l’empreinte ; ne les inventez pas à partir d’un exemple. Réservez les modifications à une copie de travail séparée. Préservez commentaires pertinents et provenance au lieu de considérer tout commentaire comme négligeable.

Commencer par un registre de preuves vierge

Couverture : référence zone/périmètre ____ ; fournisseur source et documentation datée ____ ; collecteur et méthode autorisés ____ ; instant réel et fuseau ____ ; emplacement protégé, octets et empreinte si obtenus ____ ; copie de travail ____ ; destination, mode d’import et documentation actuelle ____ ; nombres de jeux attendus, d’enregistrements individuels et exclusions ____. Une preuve indisponible reste explicitement inconnue.

Fiche annexe : fonction ou question d’autorité ____ ; documentations source et destination datées ____ ; compris, conversion nécessaire, non pris en charge ou inconnu ____ ; différence attendue ____ ; responsable ____ ; critère et preuve d’acceptation ultérieure autorisée séparément ____. Une attente documentée n’est pas une opération déjà acceptée.

Lire séparément les règles de la source et du destinataire

La page Cloudflare mise à jour le 16 avril 2026 décrit les commentaires en ligne et les tags réservés cf- exportés. cf-proxied:true et cf-proxied:false décrivent respectivement la configuration avec proxy et DNS seul. À l’import, un tag propre à l’enregistrement prime sur le choix général ; sans tag, le choix général s’applique. Conservez ce contexte sans supposer qu’un autre fournisseur le comprend ou propose un proxy équivalent.[2]

Dans le flux d’import documenté, Cloudflare accepte $ORIGIN, $TTL et $GENERATE, mais pas $INCLUDE. Le guide du portail Azure, daté du 11 août 2026, accepte $ORIGIN et $TTL et rejette $GENERATE et $INCLUDE. Un fichier adapté à un importateur ne l’est donc pas automatiquement à un autre. Avant toute opération, revérifiez produit, mode et limites actuelles.[2][1]

Azure distingue l’import lors de la création d’une zone de la fusion dans une zone existante. La fusion documentée conserve généralement les TTL des jeux existants ; un CNAME peut remplacer un CNAME existant, tandis qu’un conflit avec un autre type conserve l’enregistrement existant. L’hôte SOA et les données NS de l’apex restent contrôlés par le fournisseur ; d’autres paramètres SOA et le TTL NS de l’apex sont traités séparément. La structure des chaînes TXT peut aussi différer. Ce sont des questions de conversion délimitées, pas une restauration réalisée.[1]

Copper Lantern Archive : compter les preuves manquantes

Quatre représentés + un spécifique + un inconnu = six lignes attendues. Quatre + un = cinq jeux présents dans la source ; six − cinq = un jeu manquant. On compte des jeux, pas des lignes de fichier ni des enregistrements individuels. SOA et NS de l’apex sont volontairement exclus et notés séparément. Les symboles ne sont ni des adresses, ni des politiques SPF, ni des valeurs de vérification publiables.

Distinguer lacunes ouvertes et attentes d’autorité

G1 : le texte de R3 est présent, mais la sémantique du proxy à destination reste indéterminée. Une ligne CNAME ne prouve pas l’équivalence fonctionnelle. G2 : R6 manque dans la source décrite ; la note signale un besoin de preuve, sans autoriser une valeur à publier. Lena doit obtenir les preuves de couverture approuvées et une décision sur la fonction cible. Deux lacunes ouvertes imposent HOLD pour l’exhaustivité et l’équivalence exacte.

A1 : l’hôte SOA dépend du fournisseur. A2 : les données NS de l’apex également. Ces deux attentes documentées de conversion à destination sont hors des six jeux d’application/courriel ; ce ne sont ni des lignes manquantes supplémentaires ni des conversions effectuées. Toute modification de délégation relève d’un plan autorisé distinct. Le fichier ne prouve ni continuité du courriel ni disponibilité du site.[1]

Définir la question de l’acceptation ultérieure

Avant un import autorisé séparément, consignez produit/mode cible, création ou fusion, limites pertinentes de taille et de directives, conflits, conversions et preuves ultérieures acceptables pour chaque responsable. Le fichier et l’empreinte identifient des octets ; l’acceptation par un analyseur concerne la syntaxe dans ce contexte. Ni l’un ni l’autre ne ferme G1/G2 ni ne prouve autorité, courriel, proxy ou services fonctionnels.

Ne présentez pas l’ensemble comme une sauvegarde complète du compte. Comptes, identifiants, clés privées et configuration des services nécessitent leurs propres dispositions de récupération approuvées. Précisez les réglages représentés ou référencés ; ne supposez ni que tous les exports omettent toutes les fonctions, ni qu’un export les contient toutes.

Transmettre une décision documentaire délimitée

Livrez la référence de l’original intact, l’inventaire séparé, l’annexe fonctions/autorité, les exclusions, les responsables des points ouverts et les critères d’acceptation ultérieure. Chaque point est documenté, suspendu en attente de preuve ou accepté avec justificatif daté. Ici, HOLD demeure ; aucune autorisation d’import n’en découle. Séquence de bascule, dépendances du courriel et décision de TTL restent dans leurs guides associés.