Délégation DNS : registraires et fournisseurs DNS

La délégation DNS est le mécanisme par lequel l'autorité sur une partie de la hiérarchie des noms DNS est confiée à un autre ensemble de serveurs de noms. Un registraire de noms de domaine contrôle généralement la délégation des serveurs de noms transmise au registre, tandis qu'un fournisseur d'hébergement DNS sert les enregistrements de la zone référencée par cette délégation. Ce sont des responsabilités liées mais distinctes. Le registraire n'héberge pas nécessairement les enregistrements A, MX ou TXT, et le fournisseur DNS ne peut pas modifier la délégation du parent s'il ne gère pas aussi les paramètres côté registraire. Lorsque les enregistrements modifiés dans un tableau de bord n'apparaissent pas publiquement, une délégation incorrecte ou inattendue fait partie des premières choses à vérifier.

Suivre l'autorité du parent à l'enfant

Un résolveur récursif part d'informations racine de confiance et suit les renvois à travers la hiérarchie DNS. La racine pointe vers un domaine de premier niveau, comme .com ; le TLD pointe vers les serveurs de noms faisant autorité du domaine ; ceux-ci fournissent les enregistrements du domaine ou d'autres délégations. Chaque renvoi identifie le responsable de la partie suivante. La délégation permet à des millions de zones gérées séparément de coexister sans qu'un serveur mondial unique ait à détenir tous les enregistrements. Elle signifie aussi qu'une erreur dans un seul transfert peut rendre injoignable une zone par ailleurs correcte.

1. Créez et renseignez la zone cible chez le fournisseur DNS prévu.
2. Confirmez les noms d'hôte des serveurs de noms faisant autorité attribués par le fournisseur.
3. Définissez la délégation du domaine chez le registraire ou dans le plan de contrôle parent.
4. Vérifiez les réponses NS publiques et interrogez directement les serveurs faisant autorité.
5. Contrôlez les principaux enregistrements du site web, de la messagerie et de vérification après la bascule.

Lorsqu'un serveur de noms délégué se trouve à l'intérieur du domaine qu'il sert, des enregistrements glue chez le parent peuvent être nécessaires pour que les résolveurs trouvent l'IP du serveur sans devoir d'abord interroger ce même serveur. Les fournisseurs et les registraires guident généralement leurs clients dans cette configuration, mais les exploitants de serveurs de noms personnalisés doivent comprendre cette dépendance. Une faute de frappe, une glue manquante ou une délégation incohérente peuvent provoquer des timeouts ou des échecs même si le serveur DNS fonctionne. Les noms d'hôte de serveurs de noms standard fournis par les fournisseurs gérés évitent souvent aux clients d'avoir à gérer eux-mêmes ce détail de bas niveau.

Pourquoi le mauvais fournisseur peut sembler correct

Un tableau de bord DNS peut afficher une zone complète alors que ce fournisseur ne fait pas autorité pour le domaine public. Peut-être le domaine est-il encore délégué à un hébergeur précédent, la mise à jour chez le registraire n'est-elle pas terminée, ou un sous-domaine est-il délégué séparément. Dans ces cas, modifier la zone inactive ne change rien de ce que voient les résolveurs publics ordinaires. Vérifiez les enregistrements NS depuis l'extérieur du tableau de bord du fournisseur et comparez-les aux serveurs de noms attribués à la zone. Si un sous-domaine possède sa propre délégation NS, les enregistrements de cette branche peuvent être gérés indépendamment du parent.

Lors d'une migration de fournisseur, gardez l'ancienne zone disponible pendant la transition de la délégation et des caches. Abaisser les TTL des enregistrements à l'avance n'aide qu'une fois l'ancien TTL écoulé. Copiez les enregistrements de messagerie, de validation et de sous-domaines, pas seulement l'adresse du site web. Une fois la délégation modifiée, interrogez les nouveaux serveurs faisant autorité et comparez les réponses à la zone préparée. Une migration est terminée lorsque les noms attendus se résolvent correctement depuis l'autorité visée et que les services dépendants ont été testés, pas simplement lorsqu'un formulaire de registraire annonce un succès.

Pour aller plus loin, voyez ce qu'est un enregistrement NS, les serveurs de noms et la délégation de domaine et comment vérifier une migration DNS. Une recherche DNS publique peut montrer les réponses visibles par un résolveur, tandis qu'une requête faisant autorité aide à vérifier la zone elle-même. Distinguer la délégation chez le registraire de l'hébergement des enregistrements est la clé pour diagnostiquer où un changement DNS doit réellement être effectué.

Préparer un transfert de délégation clair

Pour un transfert de délégation propre, identifiez la date et l'heure exactes de soumission du changement chez le registraire, qui peut l'annuler et quelles vérifications de résolveur confirmeront son aboutissement. Gardez un contact faisant autorité chez l'ancien et le nouveau fournisseur DNS pendant la transition. Si le domaine utilise des serveurs de noms personnalisés ou des zones filles déléguées, intégrez ces dépendances au runbook. Une mise à jour réussie chez le registraire ne prouve pas que chaque nom d'hôte de serveur de noms se résout ni que tous les enregistrements de service ont été copiés. Vérifiez depuis l'extérieur du compte les données NS, des réponses A et AAAA représentatives, les cibles MX et les politiques TXT critiques. Vous obtenez ainsi une liste de contrôle couvrant l'autorité et les services qui reposent sur la zone déléguée. Après la transition, ne retirez l'ancien fournisseur que lorsque l'équipe a confirmé que la nouvelle autorité sert tous les enregistrements attendus et que la fenêtre de retour arrière est close. Consignez la date, les valeurs de délégation et les résultats de vérification dans le ticket de changement, afin qu'un futur administrateur comprenne quel service DNS détient le domaine.