Déléguer un sous-domaine événementiel à un autre fournisseur DNS : fiche de transfert

Déterminer si une zone enfant est nécessaire

Télécharger la fiche de transfert du sous-domaine (Markdown, anglais)

Un enregistrement A, AAAA ou CNAME dans la zone parente suffit souvent lorsqu’un prestataire veut seulement orienter un hôte vers son service. La délégation convient lorsqu’un autre opérateur doit gérer toute une branche, avec plusieurs types d’enregistrements ou noms imbriqués. Demandez ses exigences DNS exactes. Une vérification TXT ou un CNAME ne signifie pas qu’il faut déléguer par NS.[1][2]

AWS décrit les deux options : conserver les enregistrements du sous-domaine dans la zone parente ou créer une zone autoritative distincte. Cloudflare décrit la délégation, mais sa configuration de zone enfant dépend du produit et de l’offre. Vérifiez la configuration actuelle et l’éligibilité du compte.[1][3]

Nommer les responsables parent et enfant

Notez le domaine enregistré, le nom précis de la zone enfant, les deux fournisseurs DNS autoritatifs et les personnes autorisées à intervenir. Le responsable parent modifie le NS au point de délégation ; celui de la zone enfant gère les réponses en dessous. Changer les serveurs de noms du domaine chez le bureau d’enregistrement est une autre opération, inutile si seul tickets.example.org est délégué.[1]

Recensez la page événement, l’achat des billets, l’inscription, les confirmations, les e-mails, la validation du certificat et les vérifications de fournisseur dépendant de ce nom. Confirmez si un DNS public ou privé est requis : une zone privée ne crée pas seule une délégation publique. Désignez une personne qui valide l’impact sur les visiteurs et une autre qui rassemble les preuves techniques.[1]

Préparer la zone enfant avant le changement parent

Créez la zone enfant selon la documentation actuelle du fournisseur. Copiez les vrais serveurs de noms autoritatifs, jamais des exemples. Inventoriez tous les enregistrements au point de délégation et en dessous. Préparez les données web, TXT, MX et autres dans la zone enfant puis interrogez directement ses serveurs autoritatifs. Conservez réponses et heure UTC.[1]

AWS avertit que des données concurrentes dans les deux zones peuvent produire des réponses différentes lorsque les résolveurs ont mis en cache des autorités distinctes. Planifiez le retrait des anciens enregistrements sans supprimer un service actif avant que la zone enfant réponde. Si DNSSEC est actif, faites revoir la signature et le DS parent selon une procédure compatible. N’improvisez pas de valeur DS.[1][3]

Publier la délégation et vérifier la chaîne d’autorité

Quand la zone enfant est prête et le changement approuvé, l’opérateur parent publie un NS pour son nom exact avec les serveurs fournis par l’opérateur enfant. Vérifiez la réponse autoritative du parent, puis les enregistrements de service chez l’enfant. Comparez les réponses de résolveurs indépendants pendant l’évolution des caches. Une consultation publique affichant les bons NS ne prouve pas que la billetterie fonctionne.[1]

Testez la page, le lien de billets ou d’inscription, la confirmation et les e-mails qui utilisent ce nom. Vérifiez certificat et validation dans le tableau de bord du service. Consignez heure, observateur et résolveur. N’annoncez pas un délai fixe de propagation : TTL, caches et opérations varient. Si les réponses divergent, interrompez les changements dépendants et appliquez la décision de retour ou d’escalade validée.[1]

Conserver un retour arrière et un responsable durable

Le retour arrière exige un éditeur de la zone parente, les anciennes valeurs et un décideur. Restaurer les enregistrements parents suppose de tenir compte des réponses enfants encore en cache. Ne fermez pas la zone enfant tant que ses NS peuvent être utilisés. Après stabilisation, retirez les doublons obsolètes selon le plan du fournisseur et archivez les preuves avant/après.[1]

Définissez qui maintient la zone enfant, traite les futurs TXT ou certificats, paie le fournisseur, révise les accès et clôt la délégation à la fin du contrat. Sinon, le sous-domaine peut devenir une dépendance oubliée. Ajoutez-le au registre des domaines avec une date de revue. Le retour de l’autorité est lui aussi un changement DNS à préparer et tester côté visiteurs.[1]

Utiliser la fiche de transfert modifiable

La fiche téléchargeable sépare décision, dépendances, responsables, préparation, observations et clôture. Remplissez-en une par zone enfant et rangez-la avec les validations DNS. Elle coordonne les équipes ; elle ne fournit pas une suite de commandes universelle. N’y mettez ni identifiants, ni jetons API, ni codes de transfert, ni clés privées.[1]

Si les pages ou liens événementiels sont gérés avec Boletolibre.com, consignez les noms publics exacts et les tâches des participants. Suivez les instructions DNS réellement fournies pour ces noms ; ce guide ne suppose pas que Boletolibre gère votre bureau d’enregistrement ou DNS autoritatif.[1]