Choisir les TTL DNS d’une migration : consigner les hypothèses

Choisissez une attente avant un nombre

Nommez enregistrement/type permis, motif du réglage temporaire, fournisseur DNS, mode et responsable des preuves. Séparez valeur actuelle, candidate et défaut hérité. Qualifiez chaque champ de réglable, fixe ou inconnu avec référence datée. Un TTL affiché n’est pas forcément un réglage modifiable de l’enregistrement.

Cette fiche est plus limitée que le plan de bascule. Ordre de publication, contrôles opérationnels et retour restent dans ce plan ; les dépendances courrier ont leur propre revue. Ne modifiez pas des enregistrements étrangers ou la délégation pour raccourcir artificiellement une attente.

Commencez par une fiche TTL vierge

En-tête : objectif/périmètre ____ ; référence fournisseur/mode/offre datée ____ ; responsable ____ ; fenêtre/fuseau ____ ; dépendances protégées ____ ; responsable de bascule ____. Utilisez des références approuvées plutôt que secrets ou valeurs privées de zone. Répétez la fiche par enregistrement ou attente.

Vide ou inconnu exprime une limite. Ni une heure prévue ni une formule ne prouve une action exécutée. Toute observation ultérieure autorisée séparément garde sa source, son heure et son périmètre.

Séparez durée et contrôle fournisseur

RFC 8767 section 4 décrit le TTL comme durée en secondes avant de consulter à nouveau la source ; zéro se limite à la transaction en cours. Il permet conditionnellement des données expirées si l’actualisation autoritative échoue. Ce document de mars 2020 ne crée donc pas de délai de fraîcheur inconditionnel et ne dit pas que tous les résolveurs utilisent serve-stale.[1]

Cloudflare, page mise à jour le 16 avril 2026, décrit Auto 300 secondes fixe pour les enregistrements avec proxy, des options DNS seul selon l’offre et une fonction TTL de serveurs de noms distincte. Les caches locaux peuvent retarder le changement visible. Vérifiez mode réel et options actuelles : Auto et possibilité d’édition ne sont pas universels.[2]

Traitez l’absence comme une branche distincte

RFC 2308 sections 3–5 décrit la durée négative délimitée par le plus petit du TTL SOA et de SOA.MINIMUM. NXDOMAIN utilise nom/classe, NODATA nom/type/classe comme clé de cache. Délai dépassé, autre erreur ou réponse vide ne sont pas automatiquement ces cas. Demandez au responsable les preuves applicables ; aucune requête ici.[3]

Le document de mars 1998 distingue aussi $TTL, défaut du fichier maître pour les enregistrements suivants sans TTL explicite, de SOA.MINIMUM. Un candidat A/AAAA positif ou $TTL ne remplace pas les preuves négatives. Les détails historiques de signature et recommandations numériques de résolveur sont exclus ; aucun contrôle fournisseur n’est présumé accessible.[3]

Birch Lantern Migration fictive : réviser l’avance

T1 prévoit la réduction à 08:00 et la bascule à 09:30. 7200 secondes = 2 heures ; horizon simplifié 08:00 + 2 heures = 10:00. L’avance est de 90 minutes, il manque 30 minutes : RÉVISER. Même 10:00 ne prouve ni expiration de tous les caches ni préparation. Le candidat 600 ne remplace pas rétroactivement 7200 dans les réponses stockées.

T3 : min(1800,900) = 900 secondes = 15 minutes. Si un résolveur fictif stocke ce NXDOMAIN délimité à 14:05, le modèle négatif ordinaire atteint 14:20. Un usage à 14:10 intervient seulement 5 minutes après stockage, soit 10 minutes avant la fin de ce modèle. Cela reste indépendant du 600 de T1, pas un stockage mondial commun ou une absence réelle. NODATA et autres erreurs restent distincts.

Trois lignes : 1 réglage avec avance à revoir + 1 édition fixe rejetée + 1 cas négatif indépendant = 3. Aucun TTL universel, publication, vidage de cache ou retrait de cible. Mira, responsable fictive, revoit T1 seulement après les preuves de bascule acceptée et autorisées séparément, non fournies ici.

Rédigez une attente conditionnelle

Un candidat plus court peut réduire la durée normale de futures réponses en cache, avec compromis entre cache et requêtes d’actualisation. Il ne corrige ni cible défaillante, délégation, cache local ou actualisation échouée. Gardez ancien TTL et publication prévue séparés du candidat futur.[2]

Nommez les inconnues d’actualisation antérieure et de politique serve-stale conditionnelle. L’horizon simplifié peut révéler une avance insuffisante, pas établir expiration mondiale, limite effective de données périmées ou acceptation du service. Aucune recette automatique de 60/300 secondes ou 24–48 heures n’en découle.[1]

Attribuez preuves et revue ultérieure

Transmettez candidat pris en charge et motif, preuve de réglage, hypothèse ancienne, branche négative, questions et attente conditionnelle. Définissez responsable et déclencheur de revue du TTL temporaire après acceptation de la bascule distincte. Revenir à une valeur plus longue crée une autre attente ; cette fiche ne l’exécute pas et n’autorise aucun retrait.