MTA-STS la mise en cache des politiques n’est pas une mise en cache ordinaire du navigateur. Le max_age de la politique régit sa durée de vie à partir de la dernière récupération réussie. Le TXT de découverte possède son propre DNS TTL. Ces horloges peuvent différer considérablement et expliquer pourquoi deux expéditeurs appliquent simultanément des versions de politique différentes.
Enregistrez la police qu'un expéditeur pourrait encore détenir
Références : RFC 8461 §3.2, RFC 8461 §3.3.
Conservez chaque corps de politique publié, l'identifiant de découverte, l'heure de publication et max_age. Une capture d'écran actuelle du point de terminaison ne peut pas vous dire ce qu'un expéditeur a récupéré hier. Lors d'un incident, demandez la politique appliquée et récupérez l'heure dans les journaux des expéditeurs lorsqu'ils sont disponibles au lieu de supposer que le corps le plus récent est universel.
RFC 8461 indique que les expéditeurs doivent mettre en cache une politique jusqu'à max_age et doivent l'actualiser de manière proactive avant l'expiration, suggérant une actualisation quotidienne. Ces recommandations ne constituent pas une garantie de mises à jour synchronisées. Les implémentations peuvent rechercher des mises à jour à différents moments, et un expéditeur peut continuer à appliquer une stratégie de mise en cache valide lorsque la découverte ou la récupération en direct échoue.
Séparez les deux calculs d'expiration
Références : RFC 8461 §3.2, RFC 8461 §5.1.
Dans une opération arithmétique étiquetée, une politique récupérée à l'époque 1 000 000 avec max_age 86 400 a une limite d'expiration de 1 086 400. Un TTL DNS de 300 ne modifie pas ce calcul. Si l'opérateur publie un nouveau corps avec max_age 3600, l'ancien corps déjà mis en cache n'acquiert pas rétroactivement la nouvelle durée de vie.
Le nouveau luminaire hors ligne délimité calcule cette limite. L'enregistrement historique du laboratoire de transport conservé documente en outre une copie complète de l'ancien cache, une récupération de politique de plus courte durée et une affirmation selon laquelle l'ancien instantané et son expiration restent inchangés jusqu'à leur remplacement explicite. La partie cache est un modèle d'état/arithmétique explicite, pas un modèle réel. MTA, cache DNS ou planificateur d'actualisation ; les échanges DNS /HTTPS en bouclage conservés séparément n’élargissent pas cette revendication de cache. Pour étendre le test, configurez un expéditeur contrôlé avec un cache de stratégie inspectable et conservez ses journaux de récupération, d'actualisation et de livraison réels.
Mettre à jour dans l'ordre sûr
Références : RFC 8461 §8.1, RFC 8461 §8.2.
Publiez le nouveau corps HTTPS, vérifiez-le, puis modifiez l'identifiant DNS . RFC 8461 conseille de conserver les anciennes politiques compatibles avec la livraison pendant la mise à jour des points de terminaison et la transmission TXT TTL. Pour les modifications de routage planifiées, autorisez également les expéditeurs à conserver l’ancienne stratégie jusqu’à la fin de sa durée de vie ou jusqu’à ce qu’une actualisation réussie se produise.
Gardez la mise en cache des politiques de protocole distincte du cache d’origine d’un CDN. Les expéditeurs ne doivent pas utiliser la mise en cache HTTP pour la récupération des stratégies. RFC 8461 §8.2 autorise néanmoins la mise en cache du proxy inverse côté origine ; vérifiez sa fraîcheur et son comportement de publication plutôt que de traiter chaque cache proxy comme interdit. Vérifiez le corps réel à partir du point de terminaison public et assurez-vous que le flux de travail de publication d'hébergement expose la révision prévue.
Diagnostiquer un changement retardé sans deviner
Références : RFC 8461 §3.3.
Comparez les réponses DNS , les octets de réponse HTTPS, les métadonnées de stratégie mises en cache et les journaux d'échecs de l'expéditeur. Un nouvel identifiant avec un ancien corps suggère un problème de commande de publication ou d'hébergement de fraîcheur. Un ancien identifiant dans une réponse récursive peut refléter l'état du cache DNS . Une politique mise en cache ancienne mais valide lors d’une panne de récupération peut être un comportement de protocole attendu.
Ne déclarez pas que chaque retard est une propagation. Identifiez quel cache ou quelle dépendance contient l'ancien état, réparez ce composant et conservez un chemin de réception conforme tout au long de la transition. Aucune expérience de cache d'expéditeur en direct n'a été exécutée pour cet article.
Preuves historiques conservées et portée restante
Ce qui suit décrit les observations conservées du 7 novembre 2026, et non une nouvelle expérience de réseau pour cette revue. Les contrôles hors ligne nouvellement exécutés sont enregistrés séparément.
Le dispositif de cache logique capturé préserve A1 récupéré à 1 000 000 avec une expiration de 1086400. Le laboratoire publie B2, annonce B2 via une réponse DNS UDP réelle et récupère B2 sur HTTPS avec max_age 3600. Il affirme ensuite qu'un instantané A1 copié en profondeur est toujours égal à son contenu d'origine et conserve l'expiration de 1086400. Un registre distinct du dernier servi calcule l'expiration maximale possible de A1 à 1000300 + 86400 = 1086700, plus tard que B2 à 1000600 + 3600 = 1004200 et C3 à 1000900 + 3600 = 1004500. Les valeurs d'expiration sont des calculs émis en utilisant des temps logiques explicites ; la comparaison de préservation du cache est une assertion exécutée. Il ne s’agit pas non plus d’une émulation d’un planificateur d’actualisation MTA. Le choix d'un expéditeur réel d'actualiser, de réessayer ou de conserver l'état reste un test de mise en œuvre.