Migration DNS : le retour arrière commence avant la délégation
Une migration DNS peut sembler terminée alors que des résolveurs interrogent encore l’ancienne infrastructure. La méthode fiable consiste à organiser la coexistence, à tester la résolution réelle et à préserver un chemin de retour cohérent.
Article rédigé automatiquement par une intelligence artificielle, à titre informatif. Il peut contenir des imprécisions et ne constitue pas un conseil juridique.
Le scénario est classique : les zones ont été copiées, les serveurs de noms ont été modifiés et quelques requêtes retournent la réponse attendue. La migration est alors déclarée réussie. Pourtant, le DNS ne bascule pas comme une adresse IP derrière un commutateur. Les délégations et les réponses restent en cache pendant des durées différentes. Certains résolveurs continuent d’interroger les anciens serveurs, tandis que d’autres utilisent déjà les nouveaux. Une zone manquante, une vue interne oubliée ou une chaîne DNSSEC incohérente peut donc produire une panne partielle, variable selon le réseau et difficile à reproduire. Dans ce contexte, remettre l’ancienne délégation ne constitue pas un retour arrière instantané : cette nouvelle modification doit elle aussi traverser les caches.
Inventorier la chaîne complète
Un export de zone ne décrit qu’une partie du service. L’inventaire doit relier les domaines, les zones parentes et filles, les délégations, les serveurs faisant autorité, les enregistrements DS utilisés par DNSSEC, les vues internes et externes, ainsi que les mécanismes de mise à jour. Il faut aussi identifier les dépendances moins visibles : enregistrements créés par des chaînes de déploiement, validation de certificats par DNS, découverte de services, routage de messagerie et entrées utilisées pour vérifier la propriété d’un domaine. Les valeurs TTL doivent être relevées avant toute modification, y compris celles des délégations et du SOA qui influencent la mise en cache des réponses négatives. Abaisser uniquement le TTL des enregistrements applicatifs ne réduit pas nécessairement la durée pendant laquelle une ancienne délégation ou une réponse NXDOMAIN restera utilisée.
Faire coexister avant de couper
- Charger les zones sur la nouvelle infrastructure sans retirer l’ancienne, puis comparer les réponses faisant autorité en interrogeant explicitement chaque serveur. La comparaison doit couvrir les types d’enregistrements réellement utilisés, les réponses négatives, les alias et les délégations internes.
- Geler les changements DNS pendant une fenêtre maîtrisée ou les répliquer vers les deux infrastructures. Une ancienne zone devenue obsolète n’est pas un plan de reprise : elle peut restaurer la résolution tout en renvoyant vers des services qui n’existent plus.
- Tester depuis les réseaux qui comptent réellement : accès interne, accès externe, sites distants, réseaux d’administration et résolveurs imposés aux utilisateurs. Une requête directe vers un serveur faisant autorité ne valide ni les caches récursifs ni les vues séparées.
- Traiter DNSSEC comme une séquence distincte. La présence des bonnes clés sur un nouveau serveur ne suffit pas si l’enregistrement DS publié dans la zone parente ne correspond pas à la chaîne servie. Une erreur peut transformer une réponse existante en SERVFAIL pour les résolveurs validateurs.
- Définir des critères de passage avant la modification de délégation : exhaustivité des zones, réponses identiques, transfert ou synchronisation vérifiés, accès d’administration testé, supervision active et procédure de changement validée par une personne qui n’a pas construit la migration.
Observer la résolution, pas seulement les serveurs
Après la modification de délégation, la supervision doit distinguer trois réalités : l’état des nouveaux serveurs, les réponses obtenues par des résolveurs récursifs et le fonctionnement des services dépendants. Un serveur peut être disponible tout en publiant une zone incomplète. Inversement, une application peut échouer parce qu’un résolveur conserve une réponse antérieure parfaitement conforme à son TTL. Les contrôles utiles interrogent plusieurs chemins de résolution et suivent notamment les réponses SERVFAIL, NXDOMAIN inattendues, les écarts entre vues et la validation DNSSEC. L’ancienne infrastructure doit rester opérationnelle tant qu’elle peut encore être interrogée. Ses journaux donnent alors une information décisive : si elle reçoit toujours des requêtes, la coexistence n’est pas terminée. Le retrait ne doit intervenir qu’après une période d’observation cohérente avec les TTL réellement publiés et après vérification des délégations parentes. La preuve de migration n’est donc pas une capture d’écran de la console cible, mais un ensemble horodaté de requêtes, de réponses et de contrôles de service.
Le retour arrière DNS doit être testé comme une opération complète, pas seulement décrit dans un document. Il faut conserver les accès, les configurations, les clés nécessaires et une copie à jour des zones. Mais la meilleure protection reste la coexistence de réponses cohérentes : après une divergence de données, revenir vers l’ancienne infrastructure peut aggraver l’incident. Une migration DNS gagne aussi à rester isolée des changements applicatifs, de messagerie ou de certificats. Sinon, lorsqu’une résolution échoue, plusieurs causes plausibles apparaissent au même moment.
The pattern is familiar: zones have been copied, name servers have been changed and a few queries return the expected answer. The migration is then declared successful. DNS, however, does not switch like an IP address behind a network device. Delegations and answers remain cached for different lengths of time. Some resolvers continue to query the former servers while others already use the new ones. A missing zone, a forgotten internal view or an inconsistent DNSSEC chain can therefore cause a partial outage that varies by network and is difficult to reproduce. In this situation, restoring the former delegation is not an instant rollback: that additional change must also work its way through the caches.
Inventory the complete chain
A zone export describes only part of the service. The inventory must connect domains, parent and child zones, delegations, authoritative servers, DS records used by DNSSEC, internal and external views, and update mechanisms. Less visible dependencies must also be identified: records created by deployment pipelines, DNS-based certificate validation, service discovery, mail routing and entries used to prove control of a domain. TTL values must be recorded before any change, including those associated with delegations and the SOA record that affect negative-answer caching. Lowering only the TTL of application records does not necessarily reduce the time for which an old delegation or an NXDOMAIN response remains in use.
Establish coexistence before cutover
- Load the zones onto the new infrastructure without removing the former service, then compare authoritative answers by querying each server explicitly. The comparison must cover the record types actually in use, negative answers, aliases and internal delegations.
- Freeze DNS changes during a controlled window or replicate them to both infrastructures. An outdated copy of a zone is not a recovery plan: it may restore name resolution while directing traffic to services that no longer exist.
- Test from the networks that actually matter: internal and external access, remote sites, administration networks and resolvers imposed on users. A direct query to an authoritative server validates neither recursive caches nor separate views.
- Treat DNSSEC as a separate sequence. Having the correct keys on a new server is not enough if the DS record published in the parent zone does not match the chain being served. An error can turn an existing answer into SERVFAIL for validating resolvers.
- Set acceptance criteria before changing the delegation: complete zones, identical answers, verified transfer or synchronisation, tested administrative access, active monitoring and a change procedure reviewed by someone who did not build the migration.
Observe resolution, not just servers
After the delegation change, monitoring must distinguish three realities: the state of the new servers, the answers received through recursive resolvers and the operation of dependent services. A server can be available while publishing an incomplete zone. Conversely, an application can fail because a resolver retains an earlier answer that remains fully compliant with its TTL. Useful checks exercise several resolution paths and track SERVFAIL responses, unexpected NXDOMAIN answers, differences between views and DNSSEC validation. The former infrastructure must remain operational for as long as it may still receive queries. Its logs then provide decisive evidence: if requests are still arriving, coexistence is not over. Decommissioning should occur only after an observation period consistent with the TTL values that were actually published and after parent delegations have been checked. Proof of migration is therefore not a screenshot of the target console, but a timestamped set of queries, answers and service checks.
DNS rollback must be tested as a complete operation, not merely described in a document. Access rights, configurations, required keys and a current copy of the zones must be retained. The strongest protection, however, is continued coexistence of consistent answers: once data has diverged, returning to the former infrastructure may worsen the incident. A DNS migration should also remain separate from application, mail or certificate changes. Otherwise, when resolution fails, several plausible causes appear at the same time.