Modifier un enregistrement DNS avec un plan de retour arrière : abaissement du TTL, bascule et vérification

Objectif

Faire migrer un nom d'hôte vers une nouvelle adresse ou un nouveau fournisseur sans période pendant laquelle certains utilisateurs atteindraient une cible hors service, et pouvoir revenir en arrière en quelques minutes plutôt qu'en quelques heures.

Prérequis

Un accès en écriture à la zone faisant autorité, un moyen d'interroger directement les serveurs faisant autorité et les résolveurs publics (dig @server name type), et une nouvelle cible déjà en service et testée par son adresse ou sous un nom temporaire.

Étapes

1. Relever le TTL actuel. La RFC 1035 le définit comme l'intervalle de temps pendant lequel l'enregistrement peut être conservé en cache avant que la source ne soit consultée à nouveau ; tout cache détenant l'enregistrement peut le conserver jusqu'à cette durée après le changement.
2. Abaisser le TTL à quelques minutes (par exemple 300 secondes) et attendre au moins une durée complète de l'ancien TTL, afin que tous les caches qui détenaient l'enregistrement avec le TTL long l'aient laissé expirer et l'aient récupéré avec le TTL court. Omettre cette attente explique souvent pourquoi un changement semble « se propager » pendant une journée.
3. Préparer le retour arrière : noter exactement l'ancien enregistrement et laisser l'ancienne cible en service pendant toute l'opération.
4. Effectuer le changement. Vérifier d'abord les serveurs faisant autorité, puis les résolveurs publics, puis un résolveur du réseau local.
5. Surveiller l'arrivée du trafic dans les journaux de la nouvelle cible et sa diminution dans ceux de l'ancienne pendant la durée du TTL court. Ne pas arrêter l'ancienne cible tant qu'elle n'a pas cessé de recevoir du trafic pendant une durée supérieure au TTL. La RFC 8767 autorise un résolveur récursif qui ne parvient pas à joindre les serveurs faisant autorité à continuer de répondre avec des données dont le TTL a expiré, et suggère une durée maximale de conservation des données périmées comprise entre 1 et 3 jours ; cela n'entre en jeu que si les serveurs faisant autorité sont injoignables, ce qui plaide pour éviter les modifications DNS pendant un incident chez le fournisseur.
6. Une fois que l'ancienne cible ne reçoit plus de trafic, rétablir le TTL à sa valeur normale. Le retour arrière consiste à effectuer la même modification en sens inverse et prend effet après une durée de TTL court, ce qui explique pourquoi le TTL reste bas jusqu'à confirmation.
7. Consigner les deux valeurs de l'enregistrement et les horodatages dans le calendrier des changements.

Résultat attendu

Le trafic bascule en quelques minutes après le changement, aucun utilisateur n'atteint une cible hors service, et le retour arrière se limite à une seule modification d'enregistrement, avec un délai maximal connu.

Limites et base de vérification

Certains clients ignorent les TTL : connexions de longue durée, caches d'adresses des environnements d'exécution, proxys d'entreprise ; ils nécessitent un redémarrage ou dépendent de leur propre mécanisme d'expiration. La mise en cache négative d'un nom qui n'existait pas encore a son propre TTL : la RFC 2308 le fixe au minimum entre le champ MINIMUM de l'enregistrement SOA et le TTL du SOA lui-même. La procédure suit les RFC citées ; aucun délai de propagation n'est avancé au-delà du calcul fondé sur les TTL.