Objectif
Changer une cible DNS publique en limitant la durée d’une mauvaise bascule, en réduisant le TTL suffisamment tôt, en conservant l’ancienne valeur, en validant la nouvelle cible avant le changement et en contrôlant à la fois les serveurs autoritatifs et plusieurs résolveurs récursifs après la modification.
Prérequis
- Accès à la zone DNS autoritative et identification du fournisseur qui héberge réellement les NS.
- Valeur actuelle et nouvelle valeur validées.
- Nouvelle cible testable par IP ou hostname technique avant bascule.
- Plan de rollback et personne autorisée à décider du retour arrière.
- Accès à plusieurs résolveurs ou outils permettant de comparer autoritatif et cache public.
Procédure pas à pas
Confirmer l’autorité DNS et la valeur actuelle
Vérifiez les NS de la zone et assurez-vous de modifier le bon fournisseur. Capturez le type, le nom, la valeur, le TTL et les éventuels enregistrements associés. Pour un changement web, relevez aussi A, AAAA et CNAME afin de ne pas laisser IPv6 pointer vers l’ancien site alors que l’IPv4 est déjà migré.
Resolve-DnsName <DOMAIN> -Type NSResolve-DnsName <HOST> -Type AResolve-DnsName <HOST> -Type AAAA- La zone autoritative et l’état avant changement sont documentés.
Réduire le TTL suffisamment tôt
Si le planning le permet, baissez le TTL au moins un cycle de l’ancien TTL avant la bascule. Par exemple, avec un TTL de 4 heures, réduisez-le plusieurs heures avant le changement. La valeur choisie doit rester raisonnable afin de ne pas augmenter inutilement la charge DNS. Notez l’heure où la réduction a été publiée.
- La majorité des caches renouvelés utilisent le TTL réduit avant la bascule.
Tester la nouvelle cible sans modifier le DNS public
Validez le service sur la nouvelle destination par IP, hostname temporaire ou entrée hosts de test selon le protocole. Pour HTTPS, vérifiez que le certificat couvre le nom public et que le serveur répond correctement avec le bon Host/SNI
curl -I --resolve <HOST>:443:<NEW-IP> https://<HOST>/Test-NetConnection <NEW-IP> -Port 443- La nouvelle cible fonctionne avec le nom de production simulé.
Enregistrer la configuration de rollback
Copiez l’ancienne valeur dans le ticket avec son TTL et une capture ou export du fournisseur. Définissez le seuil de rollback : code HTTP critique, perte d’une application, erreur certificat, taux d’échec ou indisponibilité supérieure à quelques minutes. Le rollback doit être une décision préparée, pas improvisée sous pression.
Ancienne valeur : <OLD-IP-OR-TARGET>
Nouveau : <NEW-IP-OR-TARGET>
TTL bascule : <SECONDS>
Critère rollback : <CRITERIA>- La valeur précédente peut être restaurée immédiatement sans recherche supplémentaire.
Modifier uniquement l’enregistrement prévu
Appliquez le changement dans la zone autoritative et notez l’heure exacte. Ne restaurez pas encore le TTL. Vérifiez que le fournisseur a accepté la modification et qu’aucune autre entrée n’a été touchée. Pour une zone gérée par Windows DNS, Microsoft fournit Set-DnsServerResourceRecord ; pour un DNS hébergé, utilisez l’API ou l’interface du fournisseur.
- Le serveur autoritatif publie la nouvelle valeur avec le TTL réduit.
Interroger directement les serveurs autoritatifs
Testez chaque serveur NS ou au moins plusieurs autoritatifs afin de vérifier qu’ils répondent de manière cohérente. Cette étape sépare un problème de publication de zone d’un simple cache récursif ancien. Si un autoritatif renvoie encore l’ancienne valeur après le délai normal de réplication du fournisseur, traitez ce problème avant de conclure à une propagation Internet lente.
Resolve-DnsName <HOST> -Type A -Server <AUTHORITATIVE-NS>nslookup <HOST> <AUTHORITATIVE-NS>- Les autoritatifs renvoient tous la nouvelle valeur.
Comparer plusieurs résolveurs récursifs
Interrogez le résolveur de votre FAI, un résolveur public et si nécessaire des sondes externes. Certains caches peuvent continuer à renvoyer l’ancienne valeur jusqu’à expiration de leur TTL précédent. N’appelez pas cela une panne si le cache respecte encore la valeur publiée avant la préparation du TTL.
Resolve-DnsName <HOST> -Server 1.1.1.1Resolve-DnsName <HOST> -Server 8.8.8.8- Les résolveurs convergent progressivement vers la nouvelle cible.
Valider le service applicatif depuis plusieurs réseaux
Testez le site ou service depuis un réseau interne, un accès mobile et éventuellement un site distant. Contrôlez certificat, HTTP, API, messagerie ou autre protocole attendu. Si l’application fonctionne seulement par IP, revenez au diagnostic DNS/SNI ; si DNS est correct mais le service échoue, investiguez la nouvelle cible plutôt que modifier encore la zone.
- Le service répond avec le nom public et les dépendances critiques fonctionnent.
Déclencher le rollback si le critère est atteint
Si la nouvelle cible ne peut pas être stabilisée dans la fenêtre, restaurez l’ancienne valeur tout en conservant le TTL réduit. Vérifiez l’autoritatif puis les résolveurs comme lors de la bascule. Ne changez pas simultanément le certificat ou le firewall pour « essayer » si le plan indique un retour arrière.
- L’ancienne cible redevient publiée et le service revient à l’état précédent.
Restaurer un TTL normal après stabilisation
Attendez que le changement soit validé puis augmentez le TTL vers la valeur d’exploitation prévue. Conservez un TTL faible uniquement si des changements supplémentaires sont programmés à court terme. Documentez la valeur finale, l’heure de retour et le délai observé sur les principaux résolveurs.
- La zone retrouve un TTL normal et la bascule est documentée.
Validation
La procédure est validée lorsque :
- Les serveurs autoritatifs renvoient la nouvelle valeur.
- Les principaux résolveurs publics convergent après expiration des caches.
- Le service applicatif fonctionne depuis plusieurs réseaux avec le nom public.
- Le TTL final est restauré et l’ancienne valeur reste documentée pour l’historique.
Retour arrière
- Restaurer l’ancienne valeur exacte dans la zone autoritative.
- Conserver le TTL réduit pendant la stabilisation du rollback.
- Vérifier l’autoritatif, les résolveurs publics et l’application comme lors de la bascule initiale.
Dépannage / erreurs fréquentes
- Autoritatif correct mais certains utilisateurs voient l’ancienne IP : leur cache n’a probablement pas expiré ; vérifier le TTL précédent.
- A et AAAA pointent vers des cibles différentes : corriger les deux familles ou supprimer l’AAAA si IPv6 n’est pas supporté, selon le design.
- DNS correct mais HTTPS échoue : vérifier SNI, certificat, reverse proxy et firewall sur la nouvelle cible.
- Un seul NS publie une valeur différente : traiter la synchronisation de zone/fournisseur avant d’accuser les caches publics.